← Back to Blog Cryptography

AES-XTS: Why Disk Encryption Uses This Specific Mode

11 min read

If you have BitLocker on a Windows laptop, FileVault on a Mac, or LUKS/dm-crypt on a Linux box, the cipher protecting your hard drive is almost certainly AES-XTS. The mode is everywhere in disk encryption, and yet it gets very little attention compared to its more famous cousin AES-GCM. This is because XTS solves a very specific problem that ordinary AEAD modes cannot.

The short version is this: storage devices have hard physical constraints that make a normal authenticated cipher impossible to use. There is no room in a 4096-byte sector for an authentication tag. There is no room for a per-sector nonce. The cipher must be exactly length-preserving, must support random access, and must give different ciphertexts to identical plaintext sectors at different positions on the disk. AES-XTS is the answer NIST and the IEEE standardized for this.

This article walks through what XTS is, why disk encryption needs a special mode at all, the math of the "tweak," and the well-known trade-offs.

The Constraint That Defines Disk Encryption

A hard drive or SSD is divided into sectors, typically 512 bytes or 4096 bytes. Every sector has a fixed position on the device, indexed by Logical Block Address (LBA). When the operating system reads sector 1234, the storage controller fetches exactly that sector. When the OS writes sector 1234, the controller overwrites exactly that sector. The hardware cannot store extra metadata per sector without rewriting the entire format.

This creates a hard constraint for any disk-encryption cipher:

Length-preserving. 4096 bytes of plaintext must produce exactly 4096 bytes of ciphertext. There is no place to store a 16-byte authentication tag or a 12-byte nonce.
Random access. The OS expects to read or write any sector independently. The cipher cannot require sequential access.
Position-aware. Identical plaintext sectors at different LBAs must produce different ciphertext. Otherwise the disk leaks information about repeated sectors (think of long stretches of zeros in unused regions).

GCM, CCM, and other AEAD modes fail the length-preserving requirement. XTS is built specifically to satisfy all three.

What XTS Stands For and Where It Came From

XTS stands for XEX-based Tweaked CodeBook mode with ciphertext Stealing. The name reflects two underlying constructions: XEX (Xor-Encrypt-Xor) by Phillip Rogaway, published in 2004, and ciphertext stealing for handling sectors whose length is not a multiple of 16 bytes.

XTS was standardized by IEEE 1619 in 2007 as the cipher for the Standard Architecture for Encrypted Shared Storage Media. NIST adopted it in SP 800-38E in 2010 for use in storage device encryption. The mode is implemented in:

Microsoft BitLocker (Windows Vista and later, with XTS as the default since Windows 10).
Apple FileVault 2 (since OS X 10.7 Lion in 2011).
Linux dm-crypt with the LUKS2 container format.
VeraCrypt and TrueCrypt for cross-platform encrypted volumes.
Self-encrypting drives (SEDs) that comply with the TCG Opal specification.

The mode has been the de facto standard for full-disk encryption for over a decade.

How XTS Actually Works

XTS uses two AES keys, K1 and K2. K1 is used to encrypt the actual plaintext. K2 is used to encrypt the sector index, producing a per-sector "tweak" value. The tweak is then mixed in via XOR with each block before and after AES encryption.

For sector i and block j inside that sector, the encryption proceeds as follows. First, encrypt the sector index i under K2 to get T = AES(K2, i). Then for each 16-byte block j of the sector:

Compute T_j = T multiplied by alpha to the j in GF(2 to the 128).
Compute C[j] = AES(K1, P[j] XOR T_j) XOR T_j.

The "alpha" is a primitive element of the Galois field GF(2 to the 128), specifically the polynomial x. Multiplication by alpha is a fast shift-and-conditional-XOR operation.

The XEX (Xor-Encrypt-Xor) sandwich gives XTS its security properties. The XOR-before and XOR-after with the tweak prevent an attacker from learning anything about the AES key by looking at ciphertexts of known plaintexts at different sector positions.

What "Ciphertext Stealing" Means

XTS handles sectors whose length is a multiple of 16 bytes (the AES block size) cleanly. Standard sectors are 512 bytes or 4096 bytes, both multiples of 16, so this is the common case.

For sectors whose length is not a multiple of 16, XTS uses a technique called ciphertext stealing. The last full block of ciphertext "steals" some bytes to combine with the partial block, and the result is processed in a way that preserves length without padding. This is rare in practice but is part of the standard.

NIST SP 800-38E specifies the exact procedure. Most implementations support it because some sector formats (including some optical media and tape drives) are not 16-byte aligned.

The Position Tweak: Why It Matters

Without the tweak, XTS would degrade to ECB mode. Two identical plaintext sectors anywhere on the disk would encrypt to identical ciphertext sectors. An attacker observing the encrypted disk could see, for example, that sectors 1000 and 2000 contain the same data, even without knowing the key. This leaks structural information about the file system, directory entries, and unused (zero-filled) regions.

The position tweak fixes this. Sector 1000 has a different tweak than sector 2000, so identical plaintexts produce different ciphertexts. The tweak is derived deterministically from the LBA, so the cipher remains random-access friendly.

The tweak does not provide authentication. An attacker who can write to the encrypted disk can still flip bits in any block, and the corresponding plaintext will flip in the same position. XTS is malleable within a 16-byte block: changing one byte of ciphertext changes 16 bytes of plaintext (because AES has avalanche). Across blocks, the malleability is contained.

The Authentication Hole

XTS provides no authentication. This is the most important caveat in the entire mode. If an attacker has write access to the encrypted disk and knowledge of the plaintext, they can manipulate ciphertext to inject targeted modifications. The OS, which has no integrity check, will read the modified data and process it.

This is a real and exploited problem. The "evil maid attack" assumes an adversary with brief physical access to a powered-off laptop. They can boot a USB stick, modify selected sectors of the encrypted disk, and replace them with crafted ciphertext. When the legitimate user boots up and types their passphrase, the OS executes the attacker's payload.

Mitigations exist:

Trusted Platform Module (TPM) measurement. The TPM verifies the boot loader's integrity before releasing the disk-encryption key. A modified boot loader fails measurement and the disk stays locked.
Secure boot. The UEFI firmware refuses to load an unsigned boot loader.
File system integrity (dm-verity, Btrfs checksums, ZFS scrub). The file system catches integrity violations even when XTS itself does not.

In modern systems, XTS sits below a trusted boot chain that handles integrity at higher layers.

Key Sizes: AES-128-XTS or AES-256-XTS?

NIST SP 800-38E specifies that XTS uses two AES keys of equal length. The total key material is therefore 256 bits for AES-128-XTS or 512 bits for AES-256-XTS.

The naming is sometimes confusing. AES-256-XTS means two 256-bit AES keys, totaling 512 bits of key material. Some documentation calls this "XTS-AES-256" to distinguish from AES-XTS-128, which uses two 128-bit keys totaling 256 bits.

For long-term confidentiality, AES-256-XTS is preferred. With Grover's algorithm reducing brute-force complexity, AES-128 retains only 64 bits of quantum security, which is no longer comfortable. AES-256-XTS retains 128 bits of quantum security and is the standard for new deployments.

How Disk Encryption Software Uses XTS

The user types a passphrase. The software derives an intermediate key using a password-based key derivation function such as Argon2id (or PBKDF2 in older systems). The intermediate key decrypts a stored "volume master key" that was randomly generated when the disk was formatted. The volume master key is the (K1, K2) pair fed into XTS.

This separation lets the user change their passphrase without re-encrypting the entire disk. The passphrase change re-encrypts only the volume master key.

Why Not Use AES-GCM for Disk Encryption?

GCM is the modern AEAD default for streaming data, but it does not fit disk encryption:

GCM produces a 16-byte authentication tag per encryption operation. Storing one tag per 4096-byte sector reduces usable disk space by 0.4 percent and breaks compatibility with the underlying storage hardware.
GCM requires a unique 96-bit nonce per encryption. Where would the nonce go? The disk has no metadata field for it.
GCM is designed for sequential encryption. A disk needs random access to any sector at any time.

If a system is willing to abandon binary compatibility and store nonces and tags out-of-band (in a separate metadata sector or in a key value store), GCM-based disk encryption is possible. dm-integrity in Linux does this. But for whole-disk encryption that uses the existing sector layout, XTS is the only practical choice.

What QNSQY Uses

QNSQY operates at the file level, not the sector level. The file format uses AES-256-GCM for encryption with a 96-bit counter-based nonce and a 16-byte authentication tag stored alongside the ciphertext. The hybrid post-quantum KEM (ML-KEM with X25519) delivers the 256-bit symmetric key. Read more in Hybrid Encryption, ML-KEM Explained, and AES-256-GCM Explained.

QNSQY does not encrypt at the sector level, so XTS is not relevant for its use case. For users who also want full-disk encryption, the standard recommendation is to enable BitLocker or FileVault or LUKS underneath QNSQY for layered protection.

Quantum Resistance

XTS uses AES under the hood, so its quantum resistance equals the AES key size. AES-128-XTS drops from 128 bits classical to 64 bits quantum (broken). AES-256-XTS drops from 256 bits classical to 128 bits quantum (safe).

For long-term archival storage of sensitive data, AES-256-XTS is the minimum. NIST's post-quantum recommendation is to use 256-bit symmetric keys for any data that must remain confidential past the arrival of large quantum computers.

XTS does not protect against an attacker who steals the encrypted disk today and decrypts it after building a quantum computer. The only protection there is upgrading the cipher to a post-quantum AEAD before that day comes.

FAQ

Does XTS authenticate the data?

No. XTS provides confidentiality and a tweakable structure that prevents leaking sector equality. It does not detect tampering. Higher layers (TPM, dm-verity, file system checksums) provide integrity.

Why two keys instead of one?

Two keys cleanly separate the tweak generation from the data encryption. With a single key, the security proof of XTS becomes weaker because the same AES key encrypts both the data and the sector index.

Can XTS be parallelized?

Yes. Each block within a sector can be encrypted independently because the tweak T_j is derived from the sector index and block index, not from previous ciphertext. Modern CPUs reach gigabytes per second on AES-XTS using AES-NI.

Is XTS the same as XEX?

XEX is the underlying XOR-Encrypt-XOR construction. XTS is XEX with a specific tweak derivation (alpha multiplications in GF(2 to the 128)) plus ciphertext stealing for non-aligned sectors. XTS is the standardized form.

Why is XTS still not authenticated in 2026?

Because the storage hardware constraints have not changed. Sectors are still fixed-length, and authenticated modes still need extra bytes. Authenticated disk encryption requires a separate metadata layer (such as dm-integrity), which not all systems can afford in performance or compatibility terms.

Sources

NIST SP 800-38E: Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices. https://csrc.nist.gov/pubs/sp/800/38/e/final
IEEE 1619-2007: Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices. https://standards.ieee.org/standard/1619-2007.html
NIST FIPS 197: Advanced Encryption Standard (AES). https://csrc.nist.gov/pubs/fips/197/final
Phillip Rogaway, "Efficient Instantiations of Tweakable Blockciphers" (2004). https://web.cs.ucdavis.edu/~rogaway/papers/offsets.pdf
Microsoft BitLocker Drive Encryption Technical Overview. https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/
Apple Platform Security Guide (FileVault). https://support.apple.com/guide/security/welcome/web

Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.

Try QNSQY