AES-256-GCM: The Authenticated Encryption Standard That Secures Your iPhone Files

TL;DR

AES-256-GCM is an authenticated encryption algorithm that encrypts data and verifies its integrity using a single key and a unique nonce per message. It is defined by NIST standards, hardware-accelerated on modern iPhones, and used by TLS 1.3, WireGuard, and Signal. AppVault applies AES-256-GCM with a unique 96-bit nonce per file, a PBKDF2-derived key wrapped by the Secure Enclave, and no network calls.

AES-256-GCM is not a single algorithm. It is the combination of two standards: the Advanced Encryption Standard (AES) with a 256-bit key, and the Galois/Counter Mode (GCM) of operation. Together they form an authenticated encryption scheme that provides both confidentiality and integrity verification in one pass. It is the default cipher in TLS 1.3, WireGuard, Signal, and iOS file-level encryption. Understanding how it works matters because most security failures in AES-256-GCM come from implementation mistakes, not from breaking the cipher.

For a non-technical introduction to the underlying block cipher — what “256-bit key” means, why the keyspace is uncrackable by brute force, how AES was selected by NIST in 2001 — read the plain-language What Is AES-256 Encryption? overview first. This article goes deeper into the GCM mode specifically.

The Block Cipher: AES-256

AES is a symmetric block cipher standardized by NIST in FIPS 197. It operates on 128-bit blocks and supports key sizes of 128, 192, and 256 bits. AES-256 uses a 256-bit key and performs 14 rounds of substitution-permutation operations. Each round applies four transformations: SubBytes (non-linear substitution via S-box), ShiftRows (byte transposition), MixColumns (matrix multiplication over GF(2^8)), and AddRoundKey (XOR with round key derived from the master key).

The security margin of AES-256 is high. The best known cryptanalytic attacks are on reduced-round variants (e.g., 7-round AES-128) or on related-key models that do not apply to real-world usage. For the full 14-round AES-256, no practical attack exists that reduces the effective key size below 256 bits. This is why AES-256 is approved for Top Secret data by the U.S. National Security Agency.

AES-256 is hardware-accelerated on virtually all modern CPUs. Intel and AMD processors include AES-NI instructions. Apple Silicon (M-series and A-series chips) includes ARM Crypto Extensions that accelerate AES, SHA, and GCM operations. On an iPhone, AES-256 encryption of a 10 MB file completes in milliseconds.

The Mode: Galois/Counter Mode (GCM)

A block cipher encrypts only one block at a time. To encrypt messages longer than 128 bits, you need a mode of operation. GCM, specified in NIST SP 800-38D, is an authenticated encryption mode that combines a counter mode variant for encryption with a universal hash function (GHASH) for authentication. The same construction is registered as an AEAD primitive in IETF RFC 5116.

GCM works in two phases. First, the plaintext is encrypted using AES in counter mode: a 128-bit counter is incremented for each block, encrypted with AES, and XORed with the plaintext to produce ciphertext. The initial counter value is derived from a nonce (number used once) plus a counter starting at 1. Second, the ciphertext and associated data (metadata that must be authenticated but not encrypted) are fed into GHASH, a polynomial evaluation in GF(2^128). The GHASH output is then encrypted with AES to produce the authentication tag.

The result is a single output: ciphertext plus a 128-bit authentication tag (default length, can be truncated). The receiver decrypts by recomputing the tag and comparing it. If the tag matches, the data is authentic. If it does not, the receiver must reject the data.

GCM is parallelizable. Counter mode allows encryption of multiple blocks simultaneously, which is why hardware acceleration can achieve high throughput. On an iPhone with ARM Crypto Extensions, AES-256-GCM can encrypt at several gigabits per second.

Nonce Discipline: The Most Common Failure Point

AES-256-GCM requires a nonce. The standard specifies a 96-bit nonce. The nonce must be unique for every encryption performed with the same key. Reusing a nonce with the same key allows an attacker to recover the GHASH authentication key (H) and then forge arbitrary messages.

The math is unforgiving: if two ciphertexts share the same nonce and key, the XOR of the two GHASH outputs reveals the XOR of the plaintexts. From there, an attacker can recover H and produce valid tags for any ciphertext. This is not a theoretical attack. It has been exploited in practice, most famously in the 2015 “Nonce-Disrespecting Adversaries” paper that found nonce reuse vulnerabilities in several TLS implementations.

The correct mitigation is to never reuse a nonce under the same key. In practice, this means either generating a random nonce (96 bits gives 2^96 possibilities, but the birthday bound means you should not encrypt more than 2^32 messages with random nonces to keep collision probability negligible) or using a deterministic counter that is guaranteed unique per message.

AppVault uses a unique 96-bit nonce per file. The nonce is generated using a cryptographically secure random number generator (SecRandomCopyBytes on iOS) and stored alongside the ciphertext. Because each file gets its own nonce, and the key is derived per-install and wrapped by the Secure Enclave, the nonce reuse risk is eliminated.

Hardware Acceleration: Why It Matters

AES-256-GCM is computationally intensive in software. The GHASH multiplication in GF(2^128) is particularly expensive without hardware support. Modern CPUs include dedicated instructions that perform AES rounds and GHASH operations in a single cycle.

On an iPhone, the ARM Crypto Extensions include:

• AES instructions (AESE, AESD, AESMC, AESIMC) that perform one round of AES encryption or decryption.
• GHASH instructions (PMULL/PMULL2 for polynomial multiplication) that accelerate the GHASH computation.

The Secure Enclave in Apple Silicon includes a dedicated AES engine that can encrypt data without exposing the key to the main CPU. AppVault uses the Secure Enclave to wrap the file encryption key, ensuring that even if the main CPU is compromised, the key remains protected.

Without hardware acceleration, AES-256-GCM would be too slow for real-time applications like TLS handshakes or video streaming. With it, the overhead is negligible.

Where AES-256-GCM Is Used

AES-256-GCM is the default cipher suite in TLS 1.3 (TLS_AES_256_GCM_SHA384). Every HTTPS connection that uses TLS 1.3 relies on it. WireGuard, the modern VPN protocol, uses AES-256-GCM (or ChaCha20-Poly1305 on devices without hardware AES). Signal, the encrypted messaging app, uses AES-256-GCM for media file encryption. iOS uses AES-256-GCM for Data Protection file-level encryption.

The ubiquity of AES-256-GCM is not accidental. It is a NIST standard, hardware-accelerated, and well-understood by the cryptographic community. It is the safe default for any application that needs authenticated encryption.

Comparison with Other Authenticated Encryption Modes

AES-256-GCM is not the only AEAD mode. ChaCha20-Poly1305 is a popular alternative, especially on devices without hardware AES acceleration. ChaCha20 is a stream cipher, not a block cipher, and Poly1305 is a polynomial hash similar to GHASH. ChaCha20-Poly1305 is faster in software than AES-256-GCM in software, but on hardware with AES-NI, AES-256-GCM is faster.

AES-256-CCM (Counter with CBC-MAC) is another NIST-standard AEAD mode, but it is not parallelizable and is slower than GCM. CCM is used in some IoT and wireless protocols, but TLS and most modern applications prefer GCM.

AES-256-GCM-SIV is a nonce-misuse-resistant variant that degrades gracefully if a nonce is reused (only reveals that two messages are equal, not the plaintext). It is slower than standard GCM and less widely deployed.

For most applications, AES-256-GCM is the right choice. It is fast, standard, and secure when implemented correctly.

How AppVault Implements AES-256-GCM

AppVault uses AES-256-GCM for every file stored in the vault. The implementation follows these steps:

1. Key derivation. The user’s pattern lock is transformed into a 256-bit master key using PBKDF2-SHA256 with 600,000 iterations and a per-install 128-bit salt. This key is never used directly for encryption.
2. Secure Enclave wrapping. The master key is sent to the Secure Enclave, which generates a new key (the “wrapping key”) that never leaves the chip. The Enclave encrypts the master key with the wrapping key and returns the wrapped key to the main CPU. The plaintext master key is then zeroed from memory.
3. File encryption. For each file, a new 96-bit nonce is generated using SecRandomCopyBytes. The wrapped key is unwrapped inside the Secure Enclave and used to encrypt the file with AES-256-GCM. The ciphertext and nonce are written to storage. The authentication tag is appended to the ciphertext.
4. Catalog encryption. Even the list of files (names, dates, sizes) is encrypted with AES-256-GCM under a separate key derived from the same master key. This means an attacker with raw access to the device cannot determine how many files exist.

The result is that no two files produce the same ciphertext, even if they contain identical plaintext. The Secure Enclave ensures that the encryption key is never exposed to the main operating system. And because AppVault makes zero network calls, there is no server that could be compromised to leak keys or ciphertext.

Limitations of AES-256-GCM

AES-256-GCM does not protect against everything. It is vulnerable to side-channel attacks if the implementation leaks timing or power consumption. The GHASH computation is particularly sensitive to timing attacks; constant-time implementations are required. Apple’s CoreCrypto library provides a constant-time AES-256-GCM implementation, and AppVault uses that library.

AES-256-GCM does not provide forward secrecy. If the key is compromised, all past ciphertexts can be decrypted. Forward secrecy is achieved at the protocol level (e.g., TLS 1.3 uses ephemeral Diffie-Hellman key exchange) and is not a property of the cipher itself. AppVault mitigates this by keeping the key on-device and never transmitting it.

AES-256-GCM is not quantum-safe. Grover’s algorithm reduces the effective key size of AES-256 from 256 bits to 128 bits. A large enough quantum computer could break it. However, such a quantum computer does not exist and is not expected within the next decade. For long-term secrets, post-quantum ciphers like CRYSTALS-Kyber are being standardized.

AES-256-GCM does not protect against rubber-hose cryptanalysis or physical device seizure. If an attacker has physical access to your iPhone and can compel you to unlock it, no encryption can protect your files. AppVault’s threat model assumes the device is in your control.

Why AppVault Chose AES-256-GCM

AppVault chose AES-256-GCM because it is the most widely deployed authenticated encryption algorithm with hardware acceleration on every modern iPhone. It is standardized, peer-reviewed, and trusted by the world’s largest security protocols. It allows AppVault to encrypt files quickly without draining the battery, and its integrity verification ensures that stored files have not been tampered with.

The alternative, ChaCha20-Poly1305, is also secure and is used by AppVault for certain operations where hardware AES is not available (e.g., on older devices). But for file encryption on iOS, AES-256-GCM is the natural choice.

Every file in AppVault is encrypted with AES-256-GCM, a unique nonce, and a key derived from your pattern lock and wrapped by the Secure Enclave. The full cryptographic stack is documented on the AES-256-GCM encryption page, with citations to NIST FIPS 197, NIST SP 800-38D, and Apple’s Platform Security Guide. The threat model page explains what this architecture defends against and what it does not. The zero-knowledge architecture page explains why AppVault never sees your data.