A single reused nonce can hand an attacker the keys to an entire AES-GCM session. That is not a theoretical footnote. RFC 9325 names four real CVEs tied to TLS stacks that repeated AES-GCM nonces (CVE-2016-0270, CVE-2016-10213, CVE-2016-10212, and CVE-2017-5933), and an internet-wide scan from the IMPACT Cyber Trust project found 184 live HTTPS servers doing the same thing, breaking authenticity on every connection they served. AES-GCM-SIV exists to make that class of bug survivable. The question engineers actually need answered in September 2026 is whether the safety is worth the CPU it costs, and where each mode belongs in a real system.

Both modes wrap AES in an authenticated encryption scheme, both produce a ciphertext plus a tag, and both show up in the same standards documents you already reference for TLS and disk encryption work. The difference is what happens the moment an engineer makes a mistake with a nonce, which is a mistake real production teams keep making according to the CVE record below. This comparison walks through the specs, the sourced benchmarks from three independent research groups, the standardization status at NIST and the IETF, and a migration path, so you can pick correctly instead of guessing.

What Is AES-GCM, and Why Does Nonce Reuse Break It?

AES-GCM (Galois/Counter Mode) is the authenticated encryption mode defined in NIST SP 800-38D, first published in November 2007. It pairs AES in counter mode with a GHASH-based authentication tag, producing ciphertext and a 128-bit tag in a single pass over the data. That single-pass design is what makes AES-GCM fast: on x86 hardware with AES-NI and PCLMULQDQ instructions, the whole operation is fully parallelizable and reaches near-line-rate speeds.

The catch is the nonce. AES-GCM takes a 96-bit nonce and feeds it directly into the counter that generates the keystream. Reuse that nonce with the same key even once, and an attacker who captures both ciphertexts can XOR them together to strip out the keystream entirely, then recover the authentication key and forge arbitrary messages that will still pass the integrity check. NIST’s own guidance calls this scenario a total break, not a degraded security margin. That is why TLS 1.3 derives nonces deterministically from the record sequence number and a per-connection secret rather than trusting random generation, and why RFC 9325 spends an entire section warning implementers about it.

The authentication side works through GHASH, a polynomial hash computed over a Galois field, which lets a CPU with the PCLMULQDQ carry-less multiplication instruction process the tag in parallel with the encryption itself. That is the engineering trick that makes AES-GCM cheap: encryption and authentication happen as one combined pass rather than two separate operations bolted together. It is also why the mode is unforgiving about setup. Every security proof behind AES-GCM assumes the nonce is unique for every message encrypted under a given key. Break that one assumption and the proof, along with the confidentiality and integrity guarantees it backs, no longer applies.

What Is AES-GCM-SIV, and How Does Synthetic IV Fix That?

AES-GCM-SIV, standardized in April 2019 as RFC 8452 by Shay Gueron, Adam Langley, and Yehuda Lindell, solves the nonce problem structurally instead of relying on the caller to get it right. Rather than using the nonce as a raw counter seed, AES-GCM-SIV first derives a synthetic IV by running a keyed hash over the key, nonce, plaintext, and associated data. That synthetic IV then becomes the input to the actual encryption pass. The effect: if you accidentally reuse a nonce with AES-GCM-SIV, the algorithm degrades instead of collapsing.

The RFC 8452 authors put it directly in the spec: “This memo specifies two authenticated encryption algorithms that are nonce misuse resistant, that is, they do not fail catastrophically if a nonce is repeated.” (Shay Gueron, Adam Langley, and Yehuda Lindell, RFC 8452). The document also explains what “misuse resistant” actually means in practice: “For this class of AEADs, encrypting two messages with the same nonce only discloses whether the messages were equal or not.” (RFC 8452). That is a narrow, bounded leak compared to full plaintext and key recovery. It is not free, though, and the same authors are explicit about that trade-off, which the next two sections quantify.

Under the hood, the key derivation step runs AES itself, not a separate hash algorithm, to turn the record key, nonce, plaintext, and associated data into two sub-keys: one for the actual AES-CTR encryption and one for a POLYVAL universal hash that produces the synthetic IV. That second pass is why the mode costs more CPU than plain GCM. It also means AES-GCM-SIV never streams. The implementation has to see the full plaintext before it can compute the synthetic IV, so it fits encrypt-then-send workflows more naturally than live, low-latency streaming ones.

AES-GCM vs AES-GCM-SIV: Full Specs Comparison

Here is the side-by-side spec sheet, pulled from the governing standards documents rather than marketing copy. Sixteen rows, covering the cryptographic parameters, the standardization status, and the practical support you will actually hit when you go to implement either mode in a real codebase.

AttributeAES-GCMAES-GCM-SIV
Governing standardNIST SP 800-38D (2007)RFC 8452, IETF Standards Track (2019)
Nonce size96 bits (recommended)96 bits
Authentication tag size128 bits (down to 96 configurable)128 bits, fixed
IV constructionNonce fed directly into a counterSynthetic IV derived from key, nonce, plaintext, and AAD
Behavior on nonce reuseCatastrophic: full plaintext and key recovery possibleMisuse-resistant: only reveals whether two messages matched
Passes over the dataOne pass, fully parallelTwo passes (key derivation, then encryption)
Encryption speed vs. GCMBaselineRoughly two-thirds the speed per RFC 8452, 19-48% slower in cycle-level benchmarks below
Decryption speed vs. GCMBaselineWithin about 5% of GCM per RFC 8452
NIST approval status (2026)Approved, SP 800-38D revision comment period closed July 31, 2026Not NIST-approved, IETF-only standard
OpenSSL supportAll supported versionsAdded in OpenSSL 3.2, default provider only, not in the FIPS provider
Go standard libraryNative, via crypto/cipherNot in the standard library, third-party packages only
Python cryptography libraryNative, AESGCM classNot exposed, the library’s AESSIV class implements the different RFC 5297 scheme
Google Tink supportYes, all language bindingsYes in Java (via Conscrypt), C++/BoringSSL, Go, and Python, but not in C++/OpenSSL or Objective-C
TLS 1.3 / QUIC cipher suitesStandard, widely deployedNo defined cipher suites per RFC 9325
Typical deploymentGeneral-purpose transport encryption where nonce uniqueness is engineered and controlledKey management, envelope encryption, and systems where nonce collisions are a realistic risk

Two rows deserve a second look before you move on. The nonce size is identical, 96 bits in both modes, which means the two algorithms are not competing on how much randomness they need. They are competing on what happens after that randomness runs out or repeats, whether by bad luck, a clock reset, or a bug in a key rotation script. The other row worth sitting with is library support. A cipher’s cryptographic properties do not help a production team that cannot actually call it from their language of choice, and that gap is real for AES-GCM-SIV in 2026, not a historical footnote.

The threat AES-GCM-SIV addresses is not hypothetical. RFC 9325 documents that deployed TLS stacks have mistakenly reused AES-GCM nonces, naming CVE-2016-0270, CVE-2016-10213, CVE-2016-10212, and CVE-2017-5933 as concrete examples where that mistake made TLS sessions vulnerable to forgery and plaintext recovery. Those bugs span multiple independent implementations, which tells you the failure mode is a recurring engineering trap, not a one-off.

More recent evidence confirms the pattern has not gone away. The Nonce-Disrespecting Adversaries dataset, maintained by the IMPACT Cyber Trust project and last updated September 18, 2026, reports an internet-wide scan that found 184 HTTPS servers repeating AES-GCM nonces, a condition the researchers describe as fully breaking the authenticity of those connections and allowing attackers to inject content into what looks like a valid encrypted session. That is not 184 servers from years ago sitting unpatched. It is a live count from a dataset updated days before this article went to print.

Separately, a CVE tracking page updated September 14, 2026 documents that wolfEngine versions before 1.4.1 generated an 8-byte explicit AES-GCM nonce once when the TLS write key was set and then never incremented it, meaning every record in a TLS 1.2 or DTLS 1.2 connection used the identical key-nonce pair. A related 2026 CVE, CVE-2026-5446, covers the same class of bug in ARIA-GCM, a different block cipher using the same vulnerable mode of operation. Three independent codebases, three separate years, one repeating mistake. Implementers keep reusing nonces, and standard AES-GCM has no built-in defense against it, which is the entire reason RFC 8452 exists as a separate, deliberately harder-to-misuse mode rather than a patch to GCM itself.

Performance Benchmarks: How Much Slower Is AES-GCM-SIV?

Nonce-misuse resistance is not free, and the people who designed AES-GCM-SIV say so directly. NIST’s own technical note on the mode states plainly: “This mode is not as fast as AES-GCM because, by definition, the nonce misuse resistance property requires two passes over the data.” (NIST CSRC). The actual gap depends on message size and CPU generation, and three independent benchmark sources give a consistent picture.

SourceHardwareMessage sizeAES-GCMAES-GCM-SIVOverhead
Yehuda Lindell’s AES-GCM-SIV reference pageIntel Skylake, AES-1288,192 bytes, encrypt0.66 cycles/byte0.98 cycles/byte+48%
Yehuda Lindell’s AES-GCM-SIV reference pageIntel Skylake, AES-1288,192 bytes, decrypt0.65 cycles/byte0.69 cycles/byte+6%
Gueron & Lindell, IACR ePrint 2015/102 (CCS 2015)Intel HaswellLarge messages, encryptBaseline14% slower+14%
Gueron & Lindell, IACR ePrint 2015/102 (CCS 2015)Intel BroadwellLarge messages, encryptBaseline (0.77 C/B decrypt)0.92 cycles/byte, 19% slower+19%
Gueron & Lindell, IACR ePrint 2015/102 (CCS 2015)Intel BroadwellLarge messages, decrypt0.77 cycles/byte0.77 cycles/byte~0%
RFC 8452 (official spec text)General AES-NI hardwareMulti-kilobyte messagesBaselineAbout two-thirds of GCM speed on encrypt, within 5% on decrypt~33% (encrypt)

The pattern holds across every source. Decryption barely moves, landing within single digits of AES-GCM in every measurement. Encryption is where you pay, and the tax runs somewhere between 14% and 48% depending on CPU generation and message size, converging toward roughly a third slower for typical multi-kilobyte payloads. None of the sources surfaced an official AES-256-specific cycles-per-byte table for GCM-SIV. The numbers above are documented for AES-128, which the RFC 8452 authors treat as representative of the relative overhead, since both key sizes share the same two-pass construction and differ only in the number of AES rounds.

Put those percentages in terms an infrastructure team actually plans around. A server pushing 10 Gbps of encrypted traffic that switches every connection to AES-GCM-SIV should expect to provision roughly a third more CPU headroom on the encrypt side to hold the same throughput, based on the Broadwell figures above. A read-heavy service, by contrast, will barely notice, because decrypt-side overhead tops out around 6% even on the oldest hardware in these benchmarks. That split is the main reason production deployments tend to apply AES-GCM-SIV selectively instead of as a blanket replacement, a pattern the adoption data in the next section confirms.

Standardization Status: NIST vs IETF

AES-GCM sits inside NIST SP 800-38D, the U.S. federal standard, and that standard is currently being revised. NIST announced the revision effort in March 2024, opened a comment period for SP 800-38D Revision 1 that ran through July 31, 2026, and the second pre-draft call for comments was published in June 2026. Public comment submissions during that process specifically reference “the construction used in AES-GCM-SIV” and argue for adopting a similar approach, which signals that NIST is at least aware of the demand even though GCM-SIV itself is not part of the mainline revision. That the agency reopened this specific standard for public comment in 2026, nearly two decades after the original publication, is itself a signal that the nonce-handling ambiguity behind the CVEs above did not go unnoticed inside NIST.

AES-GCM-SIV, by contrast, lives entirely on the IETF side as RFC 8452, an IETF Standards Track document. It registers two AEAD algorithms in the IANA registry, AEAD_AES_128_GCM_SIV (ID 30) and AEAD_AES_256_GCM_SIV (ID 31). It has never gone through NIST approval, and that absence matters for any organization that needs FIPS 140-validated cryptography. OpenSSL’s own documentation confirms the GCM-SIV ciphers ship only in the default provider, not the FIPS provider. If your compliance regime requires FIPS validation, AES-GCM-SIV is currently off the table regardless of its security properties.

Real-World Adoption: Who Actually Uses Each Mode

Standards documents describe what a cipher is supposed to do. Deployment data shows what engineering teams actually trust it to do at scale, and the gap between AES-GCM and AES-GCM-SIV adoption in 2026 is wide.

AES-GCM is the default AEAD for TLS 1.3 and QUIC, which means it sits behind the majority of encrypted web traffic on the internet today. RFC 9325 documents how TLS 1.3 constructs nonces deterministically from the record sequence number, closing off the main risk that AES-GCM-SIV was designed to catch, which is a big part of why the IETF has not bothered defining GCM-SIV cipher suites for TLS at all.

Google Tink is the clearest counter-example. Tink’s supported key types table lists AES-GCM-SIV as a first-class AEAD across Java, C++ (through BoringSSL), Go, and Python, specifically aimed at key management and envelope encryption workloads where a single key wraps many independently generated data keys. That is exactly the pattern where centrally coordinated nonce counters are hard to guarantee, and it is the scenario RFC 8452 calls out by name as the mode’s intended niche.

OpenSSL crossed a real adoption threshold when version 3.2 shipped native AES-GCM-SIV support in its default provider, giving any application built on OpenSSL a supported path to the mode without pulling in a separate cryptography library. That access comes with the same asterisk noted above: the FIPS provider does not include it, so regulated deployments still cannot reach for it through OpenSSL’s compliant build.

Messaging apps show a different design choice entirely. Signal Protocol’s published cryptography uses XChaCha20-Poly1305 as its AEAD, not AES-GCM or AES-GCM-SIV, and manages the nonce-reuse risk through the Double Ratchet algorithm’s per-message key derivation instead of a synthetic-IV construction. That is a reminder that AES-GCM-SIV is one solution to the nonce problem, not the only one, and protocol designers who control the full message flow sometimes solve it at a different layer.

The AWS Encryption SDK sits on the conservative end. Its documented algorithm suites cover AES-256-GCM with and without key commitment, alongside signing combinations, but AES-GCM-SIV is absent from the list entirely as of 2026. For a service that already leans on the AWS Encryption SDK for envelope encryption, adding GCM-SIV means stepping outside that SDK rather than flipping a configuration flag.

Library and Language Support in 2026

Support for AES-GCM is close to universal. Every mainstream cryptography library ships it because TLS requires it, and any framework or SDK that touches HTTPS has had a working AES-GCM implementation for well over a decade. AES-GCM-SIV support is newer and considerably more uneven, which is the single biggest practical obstacle to adopting it. A team that decides GCM-SIV is the right fit for a given subsystem still has to check, language by language, whether the tooling exists or whether they are signing up to vendor a third-party implementation themselves.

  • OpenSSL: AES-GCM-SIV ciphers (AES-128-GCM-SIV, AES-192-GCM-SIV, AES-256-GCM-SIV) were added in OpenSSL 3.2, confirmed directly in the OpenSSL manual pages. Versions before 3.2 have no native support.
  • Go standard library: crypto/aes and crypto/cipher provide AES-GCM through cipher.NewGCM. There is no built-in AES-GCM-SIV, so any implementation has to come from a third-party package.
  • Python cryptography library: The hazmat AEAD module ships an AESGCM class and a separate AESSIV class, but AESSIV implements the older RFC 5297 scheme, not RFC 8452’s AES-GCM-SIV. There is no AESGCMSIV class in the current API.
  • Google Tink: Tink’s supported key types table shows AES-GCM-SIV working in Java (with Conscrypt installed as the JCE provider), C++ via BoringSSL, Go, and Python, but not in C++ via OpenSSL or Objective-C. Tink is the clearest example of production-grade, multi-language AES-GCM-SIV support today.
  • AWS Encryption SDK: The supported algorithm suites documentation lists AES-256-GCM with and without key commitment, plus various signing combinations. AES-GCM-SIV does not appear as a supported suite.
  • Rust: The RustCrypto aes-gcm-siv crate documents itself as “a state-of-the-art high-performance Authenticated Encryption with Associated Data (AEAD) cipher which also provides nonce reuse misuse resistance” (Rust aes_gcm_siv crate documentation), giving Rust developers a maintained, native option outside the standard library gap that Go and Python currently have.

Compute Cost Impact at Scale

Neither cipher carries a license fee, so the real “price” of choosing AES-GCM-SIV is the extra CPU it burns, which shows up as either more servers or a lower ceiling on requests per second. The table below models that overhead directly from the cycles-per-byte benchmarks above rather than any vendor pricing sheet, so treat it as a planning estimate for your own hardware, not a quote.

Workload typeBottleneckAES-GCM relative costAES-GCM-SIV relative costModeled overhead
TLS termination at high request volume (large records)CPU-bound encryption1.00x~1.48x+48% (Skylake, 8KB records)
Bulk archive or backup encryptionThroughput1.00x~1.19x to 1.33x+19% to 33%
Decrypt-heavy read paths (CDN edge, replicas)CPU-bound decryption1.00x~1.00x to 1.06x0% to 6%
Envelope key-wrap in cloud KMS (small payloads)Per-operation fixed cost1.00xMarginally higher per call, throughput impact negligibleMinimal at small sizes
Firmware or IoT updates over unreliable RNGsBreach risk, not raw cost1.00x compute, unbounded breach risk on reuse~1.2x to 1.5x compute, bounded failure on reuseSecurity trade, not a pure cost line

For a CPU-bound TLS terminator pushing large records, budgeting close to 50% more encryption-side compute is the honest number if you switch every connection to AES-GCM-SIV. For a system that is mostly decrypting, like a CDN edge node or a read-heavy database replica, the cost is close to zero. That asymmetry is exactly why most production deployments that adopt GCM-SIV apply it selectively, on the writes and key-wrap operations where nonce collisions are actually a risk, rather than swapping it in everywhere.

Scale that out to a fleet instead of a single server and the numbers become a capacity-planning question rather than an abstract percentage. A cluster that currently runs its encryption workload at 60% average CPU utilization on AES-GCM would need to plan for roughly 90% utilization on the same hardware if every write moved to AES-GCM-SIV, based on the high end of the benchmark range above. That either means adding nodes or restricting AES-GCM-SIV to the specific data paths, like key wrapping and multi-writer storage, where the nonce risk actually justifies the spend.

What the Standards and Documentation Say

The clearest signal on how each mode behaves under stress comes straight from the people who wrote the specs. On why misuse resistance matters at all, the RFC 8452 authors write: “Nonce misuse-resistant AEADs do not suffer from this problem.” (Shay Gueron, Adam Langley, and Yehuda Lindell, RFC 8452), referring directly to the catastrophic failure mode of standard AES-GCM under nonce reuse.

On the cost side, NIST’s technical note is equally direct about the trade-off, restating that the two-pass design is inherently slower than GCM’s single pass (NIST CSRC). And library maintainers frame the mode as a practical option rather than an academic curiosity: the RustCrypto project describes AES-GCM-SIV as “a state-of-the-art high-performance Authenticated Encryption with Associated Data (AEAD) cipher which also provides nonce reuse misuse resistance” (Rust aes_gcm_siv documentation). None of these sources oversell the mode as a free upgrade. They agree it is a deliberate, bounded trade of speed for a safety net against a specific, well-documented class of bug.

Pros and Cons: AES-GCM vs AES-GCM-SIV

Every fact in the sections above rolls up into a short list either way. Read both before you pick, because the case against AES-GCM is not that it is a weak cipher. It is one of the most audited AEAD constructions in production use. The case against it is entirely about what happens when a specific, narrow assumption about nonce uniqueness fails, and the case for AES-GCM-SIV is entirely about removing that single point of failure at a measured cost.

AES-GCM: pros and cons

  • Pro: NIST-approved and FIPS 140-validated, required for most government and regulated-industry deployments.
  • Pro: Fastest AEAD available on AES-NI hardware, single-pass and fully parallel.
  • Pro: Universal library support across every language and platform.
  • Con: Catastrophic failure on nonce reuse, confirmed by at least four named CVEs and an internet-wide scan finding 184 servers with the bug live in 2026.
  • Con: Requires careful nonce management (counters, sequence numbers, or large random nonces with strict uniqueness guarantees) to stay safe.

AES-GCM-SIV: pros and cons

  • Pro: Nonce reuse degrades gracefully instead of leaking the key, per RFC 8452’s own security analysis.
  • Pro: Decryption speed is nearly identical to AES-GCM, so read-heavy systems pay almost nothing.
  • Pro: Production-grade support in Google Tink across four language bindings and native support in OpenSSL 3.2+.
  • Con: Not NIST-approved, unavailable in FIPS-validated builds, and absent from TLS 1.3 and QUIC cipher suites.
  • Con: Encryption is meaningfully slower, 14% to 48% depending on hardware and message size across the benchmark sources above.
  • Con: Missing from the Go standard library, the Python cryptography library’s native AEAD set, and the AWS Encryption SDK as of 2026.

5 Use Cases: Which Cipher Fits Your System

The right choice depends less on abstract security theory and more on how your system actually generates nonces, and how much of your workload is encryption versus decryption. Walk through your own architecture against these five patterns before defaulting to whatever your framework ships with.

  1. Public-facing TLS or QUIC servers: stick with AES-GCM. TLS 1.3 already derives nonces deterministically from sequence numbers, removing the risk that GCM-SIV solves, and there are no defined cipher suites for GCM-SIV in TLS 1.3 or QUIC anyway.
  2. Cloud KMS envelope encryption and key wrapping: favor AES-GCM-SIV. This is exactly the pattern Google Tink was built to support, and small key-wrap payloads mean the performance penalty barely registers.
  3. Distributed systems with multiple independent writers sharing a key: favor AES-GCM-SIV. Any architecture where nonce coordination across nodes, replicas, or containers is hard to guarantee is precisely the failure mode RFC 8452 was written to contain.
  4. High-throughput bulk data encryption (backups, object storage): use AES-GCM if you can guarantee a strict, centrally managed nonce counter. Switch to AES-GCM-SIV if nonce generation is decentralized or relies on randomness rather than a counter.
  5. Embedded and IoT devices with weak or unaudited RNGs: favor AES-GCM-SIV. Devices that can’t guarantee high-quality random nonces are the highest-risk category for the exact bug class documented in the wolfEngine and ARIA-GCM CVEs above.

Migration Guide: Adding AES-GCM-SIV Without Breaking Production

Moving part of a system from AES-GCM to AES-GCM-SIV is not a drop-in swap. Ciphertexts are not interchangeable between the two modes, and library support gaps mean you need to check your stack before committing to a timeline. Treat this like any other cryptographic migration: plan for a period where both formats coexist, and do not flip a global switch on day one.

  1. Audit every place your system generates or stores a nonce, and classify each one as centrally counted, randomly generated, or generated by an independent writer.
  2. Confirm your cryptography library actually supports AES-GCM-SIV. OpenSSL needs version 3.2 or later, Python and Go need a third-party package or Tink, and Rust can use the aes-gcm-siv crate directly.
  3. Check whether your compliance regime requires FIPS validation. If it does, AES-GCM-SIV is not currently an option and the migration stops here.
  4. Pick the highest-risk nonce category from step 1 first, typically envelope encryption or multi-writer systems, and migrate that subsystem alone rather than the whole application at once.
  5. Version your ciphertext format so old AES-GCM records and new AES-GCM-SIV records can both be read during the transition.
  6. Benchmark the actual encryption path on your production hardware using the OpenSSL speed command below, since the overhead varies by CPU generation and message size.
  7. Roll out behind a feature flag, monitor CPU utilization on the encryption-heavy paths specifically, and compare against the modeled overhead in the cost table above.
  8. Keep the AES-GCM decryption path available for as long as any old ciphertext might still need to be read.
# Benchmark both modes on your own hardware before committing
openssl speed -evp aes-256-gcm
openssl speed -evp aes-256-gcm-siv   # requires OpenSSL 3.2+

# Confirm the GCM-SIV cipher is actually available in your build
openssl list -cipher-algorithms | grep -i gcm-siv

The Verdict: Which Should You Use in 2026?

AES-GCM stays the default for the overwhelming majority of traffic. It is NIST-approved, FIPS-validated, present in every TLS 1.3 and QUIC stack, and the fastest AEAD available on AES-NI hardware. If your nonce generation is already deterministic and centrally controlled, which is true for most well-built TLS terminators and application-layer encryption, AES-GCM-SIV buys you safety you do not need at a cost of 14% to 48% on the encryption path.

AES-GCM-SIV earns its place in a narrower but real set of systems: cloud KMS envelope encryption, distributed architectures with multiple independent writers, and embedded devices with unreliable randomness. Google Tink’s adoption of it across four language bindings, and the direct references to “the construction used in AES-GCM-SIV” in NIST’s own SP 800-38D revision comments, both point the same direction. The industry sees a real gap and is patching it selectively rather than switching wholesale. The four documented CVEs and the 184 servers found repeating nonces in 2026 are the argument for using it somewhere. The 14-to-48% encryption overhead and the missing FIPS validation are the argument against using it everywhere. Match the cipher to the nonce risk in the specific subsystem you’re protecting, not to the whole application.

If you take one number away from this comparison, make it this: decryption overhead never exceeds single digits across three independent benchmark sources, while encryption overhead swings from 14% to 48%. That gap tells you exactly where to spend the extra CPU. Put AES-GCM-SIV on the paths that write and wrap keys under conditions you don’t fully control, and leave AES-GCM everywhere your nonce generation is already deterministic and audited. That is not a compromise position. It is what the benchmark data and the standards bodies both point to when you read past the headline speed numbers.

Frequently Asked Questions

Is AES-GCM-SIV a replacement for AES-GCM?

No. It is a different mode with different ciphertext output, not a compatible upgrade. Existing AES-GCM ciphertext cannot be read by an AES-GCM-SIV decoder and vice versa, so any migration requires versioning your data format and supporting both during the transition.

Does AES-GCM-SIV work in TLS 1.3?

No. RFC 9325 notes there are no cipher suites defined for nonce-reuse-resistant algorithms like AES-GCM-SIV in TLS. TLS 1.3 addresses the nonce-reuse risk differently, by deriving nonces deterministically from the record sequence number and a per-connection secret, which is why standard AES-GCM remains the transport-layer default.

Is AES-GCM-SIV slower than AES-GCM?

Yes, on the encryption side. Benchmarks from Yehuda Lindell’s reference implementation and the original Gueron and Lindell CCS 2015 paper show encryption overhead ranging from 14% to 48% depending on CPU generation and message size. Decryption is nearly identical between the two modes, within about 5% per RFC 8452.

Is AES-GCM-SIV NIST-approved or FIPS 140-validated?

No, not as of September 2026. AES-GCM-SIV is an IETF standard (RFC 8452) and OpenSSL ships it only in the default provider, not the FIPS provider. NIST’s SP 800-38D revision process, with a comment period that closed July 31, 2026, has received public comments referencing GCM-SIV-style constructions, but the mode itself is not part of the current federal standard.

Which programming languages support AES-GCM-SIV natively?

OpenSSL 3.2 and later support it natively. Rust has a maintained RustCrypto aes-gcm-siv crate. Google Tink supports it in Java (via the Conscrypt provider), C++ with BoringSSL, Go, and Python. Go’s standard crypto library and Python’s cryptography package do not include it natively as of 2026.

What actually happens if I reuse a nonce with AES-GCM?

An attacker who captures two ciphertexts encrypted under the same key and nonce can XOR them to cancel out the keystream, then recover the authentication key and forge messages that pass integrity checks. This is documented as a total break in NIST guidance and is the root cause behind CVE-2016-0270, CVE-2016-10213, CVE-2016-10212, and CVE-2017-5933.

Does Signal or WhatsApp use AES-GCM-SIV?

No. Signal Protocol’s published design uses XChaCha20-Poly1305 for its AEAD, not AES-GCM-SIV. Its nonce-misuse concerns are handled through the Double Ratchet’s per-message key derivation rather than a synthetic-IV construction.

Should I use AES-GCM-SIV for database column encryption?

It’s worth considering if multiple application servers or workers write encrypted columns under a shared key without a single coordinated nonce counter. That decentralized-writer pattern is exactly the scenario where nonce collisions become likely, and it is the same risk profile that pushed Google Tink to prioritize AES-GCM-SIV support for key management use cases.

Can I mix AES-GCM and AES-GCM-SIV in the same system?

Yes, and it is the most common real-world pattern rather than an edge case. Teams typically keep AES-GCM on the transport layer, where TLS 1.3 already handles nonce uniqueness, and apply AES-GCM-SIV specifically to key wrapping, envelope encryption, or multi-writer storage paths where nonce coordination is harder to guarantee. Just make sure your ciphertext format records which mode produced it, since the two are not interchangeable at decrypt time.

How much extra CPU should I budget for AES-GCM-SIV?

Budget close to 50% more compute on the encryption path for large, CPU-bound workloads based on the Skylake benchmark above, and closer to 15-20% for typical multi-kilobyte payloads based on the Broadwell and RFC 8452 figures. Decryption overhead is small enough to round to zero for most capacity planning. Run the openssl speed comparison from the migration guide above on your actual hardware before finalizing any budget, since cycle counts shift meaningfully between CPU generations.