VPNSpotter

Understanding VPN encryption: AES-256, ChaCha20, and what matters

What a VPN really does, how protocols and encryption work, and what "no logs" actually means — the ground floor before you spend a euro.

8 min read

Why encryption strength actually matters

When a VPN provider plasters "military-grade encryption" across their homepage, they're usually talking about AES-256. It sounds impressive. It also tells you almost nothing about whether your data is actually secure.

Encryption is the mechanism that makes your VPN tunnel opaque to observers. Without it, a VPN is just a relay—anyone watching the wire between you and the VPN server sees everything. Strong encryption ensures that even a government agency capturing every packet can't read your traffic without the keys.

But "strong encryption" isn't a single thing. It's a combination of cipher algorithms, key exchange protocols, integrity checks, and implementation quality. A VPN can use AES-256 and still leak data if the handshake is broken, the random number generator is predictable, or the code has bugs.

This chapter explains what actually protects your data, where the real risks hide, and how to evaluate encryption claims without a cryptography degree.

The ciphers: AES-256 vs ChaCha20

AES-256: the industry standard

AES (Advanced Encryption Standard) with 256-bit keys is the default cipher for most VPNs. It's a symmetric block cipher—meaning the same key encrypts and decrypts, and it processes data in fixed 128-bit chunks.

The "256" refers to the key size. A 256-bit key means 2^256 possible combinations. For context, brute-forcing AES-128 is already computationally infeasible with current technology. AES-256 doubles the key size, making it astronomically harder—not because AES-128 is weak, but because certain regulatory and defense standards require it.

AES is fast on modern CPUs because Intel and AMD chips include AES-NI (AES New Instructions), dedicated hardware that accelerates encryption. On a recent processor, AES barely impacts performance. On older hardware or mobile devices without AES-NI, it can slow things down.

What this means for you: If your VPN uses AES-256-GCM (more on GCM in a moment) and your device is from the last 5-7 years, you're getting both security and speed. Check whether your VPN client reports "AES-NI enabled" or look for benchmarks from the provider showing hardware acceleration.

ChaCha20: the mobile-first alternative

ChaCha20 is a stream cipher designed by Daniel J. Bernstein. Unlike AES, it doesn't rely on special CPU instructions, which makes it faster on devices without hardware acceleration—most smartphones, tablets, and budget laptops.

WireGuard, the modern VPN protocol, uses ChaCha20 by default. OpenVPN supports it as a fallback when AES-NI isn't available. ChaCha20 is also the cipher behind much of Signal's encryption.

Security-wise, ChaCha20 is considered equally strong to AES-256 when properly implemented. The NSA hasn't published a preference, but the cryptographic community treats both as solid choices. The real difference is performance context: ChaCha20 wins on ARM processors, AES wins on x86 with AES-NI.

What this means for you: If you're connecting from a phone or older laptop, a VPN using ChaCha20 (especially via WireGuard) will likely give you better speeds without sacrificing security. If the provider offers both, the client should auto-select based on your hardware.

The modes: why GCM and Poly1305 matter

Encryption alone doesn't guarantee integrity. An attacker might not be able to read your traffic, but without authentication, they could potentially modify packets in transit. This is where modes of operation come in.

AES-GCM

GCM (Galois/Counter Mode) combines AES encryption with a built-in authentication tag. This "AEAD" (Authenticated Encryption with Associated Data) approach ensures that if a single bit is flipped in transit, the receiving end detects it and discards the packet.

AES-GCM is fast and parallelizable, meaning modern CPUs can process multiple blocks simultaneously. It's the current best-practice mode for AES in VPN protocols like OpenVPN and IPsec/IKEv2.

Older modes like AES-CBC required a separate HMAC step for authentication. AES-CBC is still secure when paired with HMAC-SHA256, but GCM is cleaner and faster.

ChaCha20-Poly1305

When you see "ChaCha20-Poly1305," the Poly1305 part is the authenticator. It works like GCM: one algorithm handles encryption and integrity in a single pass.

WireGuard exclusively uses ChaCha20-Poly1305. OpenVPN supports it as a cipher-authentication pair. If you're comparing VPN protocols, seeing ChaCha20-Poly1305 tells you the provider is using modern, authenticated encryption.

What this means for you: Always verify the full cipher suite, not just "AES-256." A VPN using AES-256-CBC without strong HMAC is technically encrypted but poorly configured. Look for AES-256-GCM or ChaCha20-Poly1305 in the provider's technical specs or connection logs.

Key exchange: the part most audits actually flag

The cipher protects your data in transit. The key exchange determines how securely the encryption keys are negotiated when you first connect. This is where many VPNs fail audits.

Diffie-Hellman and elliptic curves

OpenVPN and IPsec/IKEv2 rely on Diffie-Hellman (DH) key exchange or its elliptic-curve variant (ECDH). The math allows two parties—your device and the VPN server—to agree on a shared secret over an untrusted network without ever transmitting the secret itself.

The weakness: if the DH parameters are too small or reused across connections, attackers with massive computational resources (think state-level actors) can potentially crack the exchange. This is why you'll see phrases like "DH-2048" or "ECDHE with curve25519" in audit reports.

Good configurations:

  • ECDHE (Ephemeral Elliptic Curve Diffie-Hellman) with curve25519 or P-256
  • DH with at least 2048-bit parameters, preferably 4096-bit
  • Perfect Forward Secrecy (PFS) enabled—meaning keys change frequently, so compromising one session doesn't expose past sessions
Red flags:
  • Static DH keys reused across clients
  • DH parameters below 2048 bits
  • No mention of PFS in the security documentation

WireGuard's approach

WireGuard simplifies this with the Noise protocol framework, using Curve25519 for all key exchanges. It's ephemeral by default, so every session gets fresh keys. There's no configuration to mess up—either the implementation is correct, or it doesn't work.

This is part of why WireGuard is easier to audit. OpenVPN has hundreds of configuration combinations, many of them insecure. WireGuard has one path: Curve25519 + ChaCha20-Poly1305 + BLAKE2s for hashing.

What this means for you: If the VPN provider publishes technical docs or audit reports, search for "Diffie-Hellman," "ECDHE," or "Curve25519." If you see DH-1024 or no mention of PFS, that's a sign the encryption setup is outdated. For NordVPN, ExpressVPN, and similar audited providers, these details are usually in the "security whitepaper" section.

Implementation: where theory meets reality

A cipher is only as strong as its implementation. OpenSSL, the library underlying most OpenVPN deployments, has had vulnerabilities (Heartbleed, for example). WireGuard's smaller codebase—about 4,000 lines versus OpenVPN's 70,000+—reduces the attack surface, but doesn't eliminate implementation bugs.

What independent audits actually check

When a VPN provider commissions a security audit from Cure53, NCC Group, or similar firms, the auditors examine:

  • Cryptographic library usage: Are they using a well-maintained library like OpenSSL 1.1.1+, BoringSSL, or the kernel's crypto API for WireGuard?
  • Random number generation: Are session keys generated from a cryptographically secure RNG, or something predictable?
  • TLS handshake configuration: For OpenVPN, is the TLS version modern (TLS 1.2 minimum, ideally 1.3), with weak ciphers disabled?
  • Timing attacks and side channels: Does the code leak information through observable behavior like response times?
Published audit reports often list findings like "deprecated cipher suite in fallback list" or "predictable session IDs in connection manager." These aren't always critical, but they signal how seriously the provider takes encryption hygiene.

What this means for you: Don't just check if an audit exists. Read the executive summary (usually public even if the full report isn't). Look for how many "high" or "critical" findings were reported and whether the provider fixed them. Compare audit dates—one audit from 2019 with no follow-up is less meaningful than annual audits showing continuous fixes.

What doesn't matter as much as marketing suggests

"Military-grade encryption"

This phrase means "AES-256," which the U.S. military does use. So does your bank, your messaging app, and every competent VPN. It's not a differentiator—it's table stakes.

Key size beyond 256 bits

Some providers mention "up to 4096-bit RSA" for key exchange. RSA key sizes aren't directly comparable to symmetric key sizes. A 2048-bit RSA key is roughly equivalent in security to a 128-bit AES key. Going to 4096-bit RSA slows down connections with minimal security gain, because the rest of the system (AES-256, ChaCha20) is already the strong link.

Encryption at rest

A few providers advertise that their server storage is encrypted. This protects against physical server theft, but if you're trusting a "no logs" VPN, there shouldn't be sensitive session data stored in the first place. Encryption at rest matters for password managers or cloud storage, but it's orthogonal to the VPN tunnel encryption we're discussing here.

Practical encryption checklist

When evaluating a VPN, check the following (most providers publish this in a "technical details" or "protocols" page):

  • Cipher: AES-256-GCM or ChaCha20-Poly1305
  • Key exchange: ECDHE with Curve25519 or P-256, or DH-2048+ with PFS
  • Protocol: WireGuard, OpenVPN (UDP), or IKEv2—avoid PPTP and L2TP/IPsec without additional encryption
  • TLS version (for OpenVPN): TLS 1.2 minimum, TLS 1.3 preferred
  • Audit history: At least one independent security audit in the past two years with published findings
You can verify the active cipher on most clients:
  • OpenVPN logs usually show the cipher suite after connection (check console logs or enable verbose logging).
  • WireGuard always uses ChaCha20-Poly1305—if it connects, that's what you have.
  • On macOS/Linux, `tcpdump` or `wireshark` can inspect the TLS handshake if you're comfortable with packet analysis.
If the provider doesn't document this information anywhere, assume they're using defaults—which may or may not be current.

When encryption isn't your biggest risk

Strong encryption protects data in transit. It doesn't protect against:

  • Malicious VPN providers: If the VPN company itself logs traffic or sells data, encryption is irrelevant—they already have the decrypted data on their end.
  • Compromised exit nodes: If the VPN server is hacked, an attacker can see traffic exiting the tunnel before it reaches its destination (this is why a verified "no logs" policy, covered in another chapter, matters).
  • Client-side malware: If your device has a keylogger or screen recorder, the VPN can't protect you.
  • DNS leaks and IP leaks: These bypass the tunnel entirely, exposing metadata even with perfect encryption.
Encryption is necessary but not sufficient. It's one layer in a system that also requires trustworthy server operation, leak prevention, and clear data-handling policies.

Key takeaways

  • AES-256-GCM and ChaCha20-Poly1305 are both strong, modern choices—AES is faster on desktops with hardware support, ChaCha20 on mobile devices.
  • Key exchange matters more than you'd think: Look for ECDHE with modern curves or DH-2048+ with Perfect Forward Secrecy. Weak DH parameters are a common audit finding.
  • "Military-grade encryption" is marketing. What matters is the full cipher suite (encryption + authentication + key exchange), not the brand name.
  • Implementation quality shows in audits. Check if the provider publishes security audits, read the findings, and verify they addressed issues.
  • Encryption protects the tunnel, not the endpoints. Even perfect encryption can't save you from a malicious provider, DNS leaks, or compromised devices.
  • You can verify the active cipher in connection logs or protocol docs—don't just trust the homepage claims.