AES-256-GCM
Also known as: AES-GCM, AES-256 in GCM mode, Galois/Counter Mode
AES-256-GCM is an authenticated cipher pairing the AES block cipher with a 256-bit key and Galois/Counter Mode. It encrypts data using counter mode and computes a 128-bit authentication tag over the ciphertext plus any associated data in the same pass. The result gives confidentiality and tamper detection together, provided each nonce is used only once per key.
AES-256-GCM is the workhorse AEAD cipher of the modern internet — it secures most TLS 1.3 connections and a large share of messaging and disk-encryption systems. It combines two pieces. AES-256 is the Advanced Encryption Standard (FIPS 197) with a 256-bit key, run in counter mode (CTR): the cipher encrypts a counter and XORs the keystream into the data, which makes encryption parallelizable and fast. GCM (Galois/Counter Mode, standardized in NIST SP 800-38D in 2007) layers on a Galois-field universal hash, GHASH, that produces a 128-bit authentication tag covering both the ciphertext and the associated data.
In one pass you get secrecy and integrity. Flip any bit of the ciphertext or the authenticated header and the tag check fails, so the receiver rejects the message rather than returning forged plaintext.
GCM has one sharp edge: the 96-bit nonce must never repeat under the same key. A single nonce reuse lets an attacker recover GHASH's authentication key and forge messages, and it leaks the XOR of two plaintexts. That is why well-built systems generate the nonce from a strong random source or a strict counter and treat it as a hard invariant, not a suggestion.
How it works
1. Inputs: a 256-bit key, a 96-bit nonce (the recommended length), the plaintext, and optional associated data.
2. Encryption: AES in counter mode turns the nonce-plus-counter into a keystream that is XORed with the plaintext to produce ciphertext — order-independent and parallelizable.
3. Authentication: GHASH, a multiplication in the Galois field GF(2^128), is computed over the associated data and the ciphertext, then combined with an encrypted counter block to yield a 128-bit tag.
4. Output: (ciphertext, tag). Decryption reverses this and recomputes the tag in constant time; a mismatch means the message is rejected before any plaintext is released. The nonce is the load-bearing input — reuse under one key breaks the whole construction.
How RVNT uses AES-256-GCM
AES-256-GCM is RVNT's message cipher. Each Double Ratchet message key encrypts exactly one message under a fresh, random 96-bit nonce drawn from the OS CSPRNG, and the ratchet header is bound in as associated data (authenticated, not encrypted). The message key is zeroized immediately after use, so per-message forward secrecy holds. File chunks reuse AES-256-GCM under a separate content key off the ratchet. See messaging.
Frequently asked questions
Why does RVNT use AES-256-GCM instead of just AES?
Plain AES only provides confidentiality. AES-256-GCM is an authenticated mode, so it also produces a tag that detects any tampering with the message or its header. That combination — secrecy plus integrity in one pass — is what a secure messenger needs, and it is hardware-accelerated on modern CPUs.
What happens if an AES-256-GCM nonce is reused?
Nonce reuse is catastrophic in GCM. Reusing a nonce under the same key leaks the XOR of the two plaintexts and, worse, exposes the GHASH authentication subkey, letting an attacker forge valid messages. RVNT avoids this by using a fresh random nonce and a single-use message key per message.
Is AES-256-GCM quantum-resistant?
Symmetric ciphers like AES-256 hold up far better than public-key crypto against quantum attacks. Grover's algorithm only halves the effective key strength, so AES-256 still offers roughly 128-bit post-quantum security. The quantum risk in a messenger lies in the key exchange, which RVNT hardens with ML-KEM-768.
Every definition here describes something RVNT actually ships — a post-quantum, end-to-end-encrypted, peer-to-peer messenger with no phone number and no servers.