AES-256 Encryption Explained in Plain Language

What is AES-256, in plain terms?

AES-256 is a method for scrambling digital data so that, without the correct key, it looks like meaningless noise — and with the correct key, it can be turned back into the original data perfectly. AES stands for Advanced Encryption Standard, and the "256" refers to the length of the key used to lock and unlock the data, measured in bits. It's called a symmetric cipher because the same key is used for both encrypting the data and decrypting it later, as opposed to asymmetric cryptography, which uses a mathematically related pair of different keys — one public, one private.

You'll see "AES 256 encryption" mentioned constantly in VPN marketing, usually paired with a phrase like "military-grade," but the underlying algorithm itself is not exclusive to VPNs or to any single company. AES-256 is a public, standardized specification that anyone can implement, and it's used to encrypt everything from the password manager on your phone to the full-disk encryption on a company laptop to the messages sent through many secure messaging apps. A VPN provider using AES-256 correctly is using the same well-vetted algorithm as thousands of other security products — the cipher itself isn't a differentiator between VPN providers so much as a baseline expectation.

Where did AES-256 come from, and who decides it's trustworthy?

AES wasn't invented by a VPN company or kept secret by any single organization — it was the winner of a public, multi-year competition run by the U.S. National Institute of Standards and Technology (NIST) in the late 1990s. NIST was looking for a replacement for the aging Data Encryption Standard (DES), whose 56-bit key had become crackable by brute force as computing power grew. Cryptographers from around the world submitted candidate algorithms, and independent researchers spent years publicly attacking and analyzing each one, looking for weaknesses. The algorithm that won, originally called Rijndael after its Belgian designers Joan Daemen and Vincent Rijmen, was formally adopted as the Advanced Encryption Standard in 2001, published as U.S. Federal Information Processing Standard 197 (FIPS 197).

That open, adversarial vetting process is a big part of why AES-256 is trusted today. Cryptographic strength isn't something a company can credibly claim about its own private algorithm — the field generally treats "security through obscurity" as a red flag rather than a strength, because an algorithm that hasn't survived public scrutiny hasn't actually been tested against the world's best cryptanalysts. AES has now been public, standardized, and subjected to over two decades of attempted attacks by academic and government researchers alike, with no practical break of the full algorithm found. That track record — not a marketing claim — is the actual basis for calling it strong.

How does AES-256 actually encrypt data, step by step?

At a high level, AES-256 works by taking your data in fixed-size chunks called blocks (128 bits each, regardless of whether you're using AES-128, AES-192, or AES-256) and running each block through a series of repeated transformation steps, called rounds, using a key schedule derived from your original 256-bit key. AES-256 specifically uses 14 rounds — more than AES-128's 10 rounds or AES-192's 12, because a longer key schedule needs more rounds to fully diffuse its influence across the data and resist certain theoretical attacks that shrink with fewer rounds.

Each round applies four distinct operations to the block of data:

• SubBytes. Every byte in the block is replaced with a different byte, according to a fixed lookup table called an S-box. This step introduces non-linearity — meaning the relationship between the input and output isn't a simple, predictable pattern — which is essential for resisting mathematical shortcuts that could otherwise be used to reverse the encryption without the key.
• ShiftRows. The block, which is conceptually arranged as a 4x4 grid of bytes, has its rows shifted cyclically by different amounts. This step spreads individual bytes across different columns of the grid, so a change in one part of the data eventually affects the whole block rather than staying isolated.
• MixColumns. Each column of the grid is transformed using a matrix multiplication over a specific mathematical field, mixing the bytes within that column together. Combined with ShiftRows, this is what makes AES a strong "diffusion" cipher: change a single bit of input, and after a few rounds, roughly half the bits of the output change in a way that appears essentially random relative to the original change.
• AddRoundKey. A portion of the key schedule — a different 128-bit chunk derived from your original key, generated fresh for each round — is combined with the block using a bitwise XOR operation. This is the step that actually ties the encryption to your specific secret key; without knowing the key schedule, an attacker can't reverse this step even if they understand every other part of the algorithm perfectly.

These four steps repeat for all 14 rounds (with a slightly modified first and last round), and the result is ciphertext: a block of data that's fully determined by the original data and the key, but that reveals no practical, exploitable pattern to someone who doesn't have the key. Decryption runs the same process in reverse, using inverse versions of each operation, which only produces the correct original data if you start with the correct key.

None of this happens manually, of course — your device's processor executes billions of these operations per second, which is why AES-256 encrypting an entire VPN connection, including video streaming and large downloads, doesn't feel slow on modern hardware. Many processors even include dedicated AES instructions built directly into the chip (a feature called AES-NI on Intel and AMD processors, and equivalent instruction sets on most modern ARM chips used in phones), which perform these rounds in hardware rather than software, making AES-256 dramatically faster than it would be if the CPU had to compute every step through general-purpose instructions.

Why 256 bits specifically? What does the key size actually protect against?

A "256-bit key" means the key is a string of 256 binary digits — 256 ones and zeros — which gives 2²⁵⁶ possible different keys. That number is difficult to grasp intuitively because it's so far outside normal human experience with quantities, but the relevant point isn't the number itself so much as what it means for an attacker trying to guess the key by brute force: trying every possible key, one at a time, until one happens to work.

To put the scale in perspective without resorting to an ungrounded comparison: 2²⁵⁶ is vastly larger than the estimated number of atoms in the observable universe (commonly estimated in the range of 10⁷⁸ to 10⁸²), while 2²⁵⁶ is roughly 1.16 x 10⁷⁷. Even a hypothetical attacker with access to every computer on Earth running continuously, or a nation-state-level dedicated cracking cluster, would need a length of time vastly longer than the current age of the universe to have a realistic chance of stumbling onto the correct key through brute-force guessing alone, given current and foreseeable computing speeds. This isn't a claim about a specific test anyone has run — it's a direct consequence of how exponential growth works: doubling a key's bit length doesn't double the difficulty of brute-forcing it, it squares the size of the keyspace that needs to be searched.

This is also why key size comparisons between AES-128 and AES-256 can be a little misleading if taken too literally. AES-128, with a keyspace of 2¹²⁸, is also considered infeasible to brute-force with any known or realistically foreseeable computing technology — the extra 128 bits in AES-256 aren't closing a practical gap in brute-force resistance so much as adding an enormous additional safety margin, partly as insurance against future advances in computing (including quantum computing, discussed further below) that nobody can predict with certainty decades in advance.

Is AES-256 the same thing as "military-grade encryption"?

"Military-grade encryption" is a marketing phrase, not a technical classification, and it's worth being clear-eyed about what it does and doesn't mean. AES-256 is indeed approved by the U.S. National Security Agency for encrypting classified information up to the Top Secret level, which is the origin of the phrase — VPN marketing teams reasonably note that the same cipher protecting classified government data is the one protecting your VPN traffic. But "military-grade" doesn't describe a stronger, different, or specially hardened variant of AES that only certain organizations get access to. It's the identical, publicly published AES-256 algorithm that any developer can implement, the same cipher used in consumer password managers, banking apps, and messaging services that have nothing to do with any military or government use.

When a VPN provider says "military-grade encryption," a reasonable translation is simply "we use AES-256," which is a legitimate and accurate thing to say — but it isn't evidence of some proprietary enhancement, and a provider that phrases it that way isn't offering you something meaningfully different from a competitor that plainly states "AES-256" without the marketing flourish. Providers that use the phrase without further specifics (which cipher mode, which key exchange, which protocol) are giving you a memorable label rather than a technical spec — worth knowing, but not worth treating as a meaningful differentiator when comparing providers.

How is AES-256 different from AES-128 and AES-192?

AES actually comes in three standardized key sizes — 128-bit, 192-bit, and 256-bit — and all three are part of the same FIPS 197 specification, differing only in key length and the corresponding number of transformation rounds (10 for AES-128, 12 for AES-192, 14 for AES-256). All three are currently considered secure against any known practical attack; there is no publicly known method to break the full, correctly implemented version of any of them faster than brute force, and brute force is infeasible for all three given current and foreseeable computing power.

In practice, most VPN providers default to AES-256 rather than AES-128, even though AES-128 is also considered secure, largely because the performance difference on modern hardware with AES acceleration is small enough that there's little reason not to use the larger margin. AES-192 is comparatively rare in consumer software; it exists in the standard but doesn't see much real-world deployment, since most systems either standardize on AES-128 for maximum speed on constrained devices or AES-256 for maximum margin, with less demand for a size in between. If you're comparing VPN providers, seeing "AES-256" specifically (rather than an unspecified "AES encryption") is a reasonable, if modest, positive signal that the provider is being specific about its implementation rather than leaving the detail vague.

What do "AES-256-GCM" and "AES-256-CBC" mean, and does the mode matter?

AES itself defines the block cipher — how a single 128-bit block gets transformed using the key — but a real-world protocol needs to encrypt messages far longer than a single block, and it needs a defined way of chaining blocks together and handling the last, possibly incomplete block. That's what a "mode of operation" specifies, and it's why you'll often see AES-256 written with a suffix like GCM or CBC attached.

CBC (Cipher Block Chaining) is an older mode where each block of plaintext is combined with the previous block's ciphertext before being encrypted, chaining blocks together so that identical blocks of input don't produce identical blocks of output — an important property, since without chaining, patterns in the original data could remain visible in the encrypted result. CBC on its own only provides confidentiality (keeping data secret), not built-in authentication (proof that the data wasn't tampered with in transit), which historically required pairing it with a separate authentication step.

GCM (Galois/Counter Mode) is the mode used by most modern VPN implementations, including WireGuard and current OpenVPN configurations that specify AES-256-GCM. GCM combines encryption with built-in authentication in a single, more efficient operation — it doesn't just scramble the data, it also generates an authentication tag that lets the receiving side verify the data wasn't altered or corrupted in transit, without needing a separate cryptographic step. This combined approach (called "authenticated encryption") is both faster and more resistant to certain classes of tampering attacks than older combinations of CBC plus a bolted-on authentication step, which is why the cryptographic community has broadly shifted toward authenticated modes like GCM for new protocol designs over the past decade or so.

For a VPN user, the practical takeaway is narrow but useful: if a provider specifies "AES-256-GCM" rather than a bare "AES-256," that's a genuinely meaningful detail — it tells you the connection isn't just encrypted but also authenticated against tampering, using a modern, efficient mode rather than an older combination. It's a legitimate thing to look for in a provider's technical documentation, though its absence from a marketing page doesn't necessarily mean a provider is using something weaker — many simply don't specify the mode in consumer-facing copy even when GCM is what's actually running under the hood.

Can AES-256 be brute-forced? How long would it actually take?

In principle, any symmetric cipher can be brute-forced given enough time and computing power — the question that actually matters is whether that amount of time is realistically achievable, and for AES-256, it isn't, by an enormous margin. A brute-force attack means trying every possible key, one after another, until the correct one is found; on average, an attacker would need to try about half of the total keyspace before expecting to hit the right one.

The often-cited illustrative comparison (not a claim about any specific real hardware, but a way of grounding the abstract math) is this: even a hypothetical machine capable of testing a billion billion (10¹⁸) keys per second — vastly beyond any publicly known computing cluster today — would still need roughly 10⁵⁰ years or more, on average, to work through a meaningful fraction of a 2²⁵⁶ keyspace. For context, the universe is currently estimated to be around 1.4 x 10¹⁰ years old. The gap between those two numbers isn't a rounding error or a matter of "give it a few more decades of Moore's Law" — it's the kind of gap that would require a categorically different kind of computing than brute force to meaningfully close, and no such approach against AES-256's full keyspace is currently known to exist.

This is why, when security researchers do publish attacks on AES, they virtually never target the raw brute-force problem — they look instead for mathematical shortcuts (cryptanalytic attacks) that might reduce the effective search space, or they target the implementation surrounding the cipher (weak key generation, side-channel leaks through power consumption or timing, poor random number generators) rather than the algorithm's core math. That distinction — attacking the math versus attacking the implementation around the math — matters a lot for understanding real-world AES security, which the next section covers.

Has AES-256 ever actually been broken?

No practical break of full, correctly implemented AES-256 has been published. It's worth being precise here, because "AES has been broken" claims do circulate, and most conflate a few genuinely different things:

• Theoretical cryptanalytic attacks exist, but none are practical. Academic researchers have published attacks — for example, "related-key" attacks against reduced-round versions of AES, or biclique attacks that shave a small, specific amount off the theoretical brute-force effort — that are real cryptographic findings and genuinely interesting to the field. None of them come remotely close to making an attack computationally feasible; the best published attacks against full AES-256 still require an amount of computation far beyond anything achievable with current or foreseeable technology, and several notable published attacks apply only to a reduced-round variant of AES that isn't the version actually used in real products, or require attack conditions (like access to related keys under specific, contrived circumstances) that don't occur in normal VPN or application use.
• Implementation flaws are a real, separate risk. Real-world security failures involving AES almost always trace back to something other than the algorithm itself: a poorly generated or reused key, a side-channel vulnerability where an attacker measures power consumption or timing to infer bits of the key indirectly, a flawed random number generator that makes keys predictable, or a software bug in how a specific product implements the surrounding protocol. These are legitimate security concerns, and they're the reason implementation quality and independent code audits matter for VPN software — but they're a different category of problem than the AES-256 cipher itself being mathematically broken.
• "Broken" sometimes gets used loosely for older, unrelated protocols. Confusion sometimes arises because older VPN protocols like PPTP had genuine, well-documented cryptographic weaknesses — but those weaknesses were in PPTP's own encryption scheme (MPPE), not in AES, and PPTP is now considered obsolete and unrelated to how AES-256 is used in current WireGuard or OpenVPN deployments.

The honest summary: AES-256 has survived over two decades of sustained attack from the global cryptographic research community, and nothing in that record undermines its use as a symmetric cipher today. That doesn't mean encryption is the only thing that can go wrong in a VPN's overall security — it means the cipher specifically has held up.

Is AES-256 safe from future quantum computers?

This is a fair and increasingly common question, and it deserves a direct answer rather than either dismissal or exaggeration. The concern with quantum computing and cryptography is specific: a sufficiently powerful quantum computer running an algorithm called Shor's algorithm could, in theory, efficiently solve the mathematical problems that asymmetric cryptography relies on — like the elliptic-curve key exchange used in a VPN's handshake — far faster than any classical computer could. That's a real long-term consideration for the handshake portion of a VPN connection, and it's discussed at more length in our guide to how VPN encryption works overall.

Symmetric ciphers like AES-256 are in a meaningfully different, more resilient position. The best known quantum algorithm applicable to brute-forcing a symmetric cipher, Grover's algorithm, provides at most a quadratic speedup — which sounds significant until you do the math: it would reduce AES-256's effective brute-force resistance to roughly the strength of a 128-bit key, not to something remotely crackable. A 128-bit-equivalent keyspace, even against Grover's algorithm, remains completely infeasible to brute-force with any quantum computing capability that's been demonstrated or credibly projected. This is precisely why AES-256, rather than AES-128, is the recommended choice in most post-quantum security guidance for symmetric encryption specifically — the larger key size already builds in the safety margin that quantum computing's known threat to symmetric ciphers would erode.

No quantum computer capable of running Grover's algorithm at a scale that threatens AES-256 in practice exists today, and credible timelines for when — or whether — one might are genuinely uncertain and actively debated within the field. The more time-sensitive quantum concern for VPN users is actually the handshake, not the AES-256 bulk cipher, since an adversary recording encrypted handshake traffic today (a scenario called "harvest now, decrypt later") could theoretically decrypt the key exchange years from now if a capable quantum computer eventually exists — this is why some providers have begun offering post-quantum key exchange options alongside their existing AES-256 bulk encryption.

Why do almost all VPN providers use AES-256 specifically?

Several practical factors converge to make AES-256 the default choice across the VPN industry, rather than any single provider inventing a superior standard: it's a free, open, standardized algorithm that any developer can implement without licensing fees; it has more than two decades of public cryptanalysis behind it with no practical break found; it runs fast on essentially all modern consumer hardware thanks to dedicated AES instruction sets built into the processors; and it's already the trusted standard across banking, government, and enterprise security, which gives VPN providers a recognizable, defensible claim to make rather than asking users to trust an unfamiliar or proprietary algorithm.

Regulatory and compliance pressure plays a role too — providers serving business customers, or operating in jurisdictions with data-protection requirements, often need to point to a widely recognized standard like AES-256 rather than something homegrown, since auditors and compliance frameworks are built around recognized standards. Put together, there's little competitive incentive for a VPN provider to use anything other than AES-256 (or, for the handshake and sometimes the bulk cipher on WireGuard connections, ChaCha20, which is comparably strong and discussed in more detail below) — a provider using AES-128 isn't using something meaningfully weaker in practice, but AES-256 has become the de facto expected answer to "what encryption do you use," and most providers simply meet that expectation.

Does using AES-256 encryption slow down my VPN connection?

The AES-256 algorithm itself is not typically the bottleneck in a modern VPN connection's speed. On hardware with dedicated AES acceleration — which covers the overwhelming majority of laptops, desktops, and phones sold in the past decade — encrypting and decrypting data with AES-256 happens fast enough that it rarely becomes the limiting factor for typical browsing, streaming, or downloading. The processing overhead is real but small relative to other factors that affect a VPN connection's measured speed: the physical distance to the server you've connected to, how many other users are sharing that server's capacity at the time, the underlying protocol's efficiency (WireGuard, for instance, is generally faster than OpenVPN independent of which cipher either one uses), and your own internet connection's baseline speed and latency.

If you're troubleshooting a slow VPN connection, the cipher is rarely the first thing worth investigating — switching to a closer server location or trying a different protocol (if your provider's app offers a choice) will generally have a larger, more noticeable effect than anything related to AES-256 specifically. On genuinely older or lower-power devices without AES hardware acceleration, the difference can be more noticeable, which is part of why WireGuard's default cipher, ChaCha20, was specifically engineered to perform well in pure software without needing dedicated hardware — but this is a narrower edge case than it might sound, since it mainly affects older or budget mobile chipsets rather than typical modern laptops and phones.

AES-256 vs. ChaCha20: is one actually better for a VPN?

ChaCha20 is the other cipher you'll commonly encounter in VPN settings, typically as WireGuard's default rather than an optional alternative. Both AES-256 and ChaCha20 are considered cryptographically strong by current standards, and there's no meaningful security gap between a well-implemented deployment of either one — the difference is primarily architectural and performance-related rather than a matter of one being more "secure" in a way that should change your practical decision-making.

AES-256 has the advantage of dedicated hardware acceleration on most modern devices, which makes it extremely fast in that context, plus the longest public track record of any widely deployed modern cipher. ChaCha20 was designed later, specifically to run fast in software without needing that hardware support, which makes it a strong choice for WireGuard's goal of being lean and consistent across a very wide range of devices, including older or lower-power hardware where AES-256 might run somewhat slower without acceleration. Neither cipher has a known practical vulnerability that should drive your choice of VPN provider — if a provider offers a choice between protocols that default to different ciphers, picking based on connection speed and stability for your specific device and network is a more useful decision criterion than trying to rank the ciphers by theoretical security margin. For a deeper comparison of the protocols each cipher is typically paired with, see our full guide to how VPN encryption works and our guide to VPN protocols.

Where else is AES-256 used, besides VPNs?

AES-256 is genuinely everywhere in modern computing, which is part of why it's a reasonable, well-tested choice for a VPN rather than an untested newcomer being applied to internet traffic for the first time. Full-disk encryption tools built into major operating systems — BitLocker on Windows and FileVault on macOS — use AES, typically at 256-bit strength, to protect the contents of a hard drive if a device is lost or stolen. Password managers encrypt your stored credentials with AES-256 before they ever leave your device. Many secure messaging apps use AES-256 as part of their end-to-end encryption scheme for message content. Cloud storage providers commonly encrypt files at rest with AES-256. Wi-Fi security itself, in the WPA2 and WPA3 standards used by most home and business routers, relies on AES for encrypting wireless traffic between your device and the router.

This broad deployment across such different contexts — protecting a hard drive is a very different problem from protecting a live network connection — is itself informative: AES-256 isn't a VPN-specific solution engineered for one narrow use case, it's a general-purpose cryptographic primitive that's been independently adopted across the security industry because it solves the underlying problem (turning readable data into unreadable data reversibly, with a secret key) reliably and efficiently, regardless of what kind of data is being protected.

How can I verify a VPN actually uses AES-256, rather than just claiming it?

Since AES-256 is a specific, standardized algorithm rather than a vague marketing category, there are a few concrete ways to check a provider's claim rather than taking a homepage badge at face value.

• Check the app's settings or connection details. Many VPN apps display the active cipher and protocol somewhere in their connection status screen or advanced settings, often labeled something like "Encryption," "Cipher," or shown alongside the protocol name (for instance, "WireGuard (ChaCha20)" or "OpenVPN (AES-256-GCM)").
• Read the provider's technical documentation, not just its marketing page. Providers serious about their technical claims usually publish a dedicated security or technical specifications page — sometimes as part of a knowledge base or support documentation — that states the specific cipher, mode, and key exchange method used, which tends to be more precise and less rounded-up-for-marketing than homepage copy.
• Look for independent audits of the client apps or protocol implementation. A third-party security audit that specifically examined the app's cryptographic implementation is a stronger signal than a self-reported claim, because it means someone outside the company checked the actual code rather than just trusting the provider's description of what the code does. When we reference a specific audit anywhere on this site, we link to the actual audit report and note its date and scope, rather than treating "audited" as an unqualified blanket claim.
• Check if the app is open source, where applicable. Some providers, notably including some of WireGuard's own reference implementation and certain provider apps, publish source code that independent researchers can inspect directly, which is the most direct way to verify what cipher and mode is actually being used in practice, as opposed to what's advertised.

None of these checks require a cryptography background — they're mostly about knowing where to look (settings screens and technical documentation rather than marketing pages) and applying a reasonable amount of skepticism to unqualified claims like "military-grade" without a specific cipher name attached.

Common myths about AES-256, debunked

A handful of misconceptions about AES-256 come up often enough in VPN marketing and casual discussion to be worth addressing directly.

Myth: A bigger key number always means meaningfully better real-world security. AES-128 is also currently considered secure against any known practical attack; the extra key length in AES-256 is a larger theoretical safety margin, not a fix for a practical weakness in AES-128. The more consequential factors for real-world VPN security are usually the mode of operation (GCM versus older alternatives), the protocol's handshake and authentication design, and implementation quality — not which of the two already-secure key lengths is in use.

Myth: "Military-grade" means a special, stronger version of AES exists for security products. As covered above, it's the same publicly standardized AES-256 algorithm used everywhere else; the phrase describes AES-256's approval for government classified use, not a distinct or enhanced variant of the cipher.

Myth: If AES-256 is unbreakable, my VPN traffic is completely safe no matter what. AES-256 encrypting your traffic between your device and the VPN server says nothing about what the VPN provider does with that traffic once it's decrypted at their server, what they log, whether their apps have unrelated security bugs, or whether your device itself is compromised upstream of the encryption. A strong cipher is a necessary piece of a secure VPN, not a complete guarantee on its own.

Myth: AES-256 was designed by a VPN company or a single country's government, so it might have a hidden backdoor. AES was selected through an open, international public competition, and its design and specification are fully published for anyone to inspect; there's no secret or proprietary component that any single entity controls, and its design process is a large part of why the wider cryptographic community trusts it, as opposed to a closed-source or classified algorithm.

Myth: Encryption strength is the main thing that separates a good VPN provider from a bad one. Nearly every reputable provider today uses AES-256 or ChaCha20 correctly, so the cipher itself is rarely the differentiator worth spending your comparison time on. Logging policy, jurisdiction, app security track record, independent audits, transparency about incidents, and how the company actually handles the data it does collect tend to matter far more for your real-world outcome than which already-strong cipher is listed on the settings screen.

Practical takeaway

AES-256 is a real, well-tested, standardized cipher — not a marketing invention — and the "aes 256 encryption vpn" claim you see on nearly every provider's homepage is, in the overwhelming majority of cases, an accurate and reasonable one to make, because AES-256 genuinely is currently considered infeasible to brute-force and has held up against more than two decades of public cryptanalysis. Where it stops being useful as a comparison tool is once you realize almost every credible VPN provider uses it, or the comparably strong ChaCha20, correctly — so the cipher's presence tells you a provider meets a baseline expectation, not that it's better than a competitor making the identical claim. The more useful questions to ask when comparing providers are the ones AES-256 alone can't answer: which mode is actually used (GCM is a meaningfully modern detail worth looking for), what the provider's logging policy actually says, whether independent audits back up their claims, and what happens to your data once it reaches their servers and gets decrypted. Understanding AES-256 itself is what lets you read past the "military-grade" badge and evaluate those remaining, more consequential questions with clear eyes.