# Is XTS always better than GCM?

XTS is suitable for disk encryption while GCM doesn't. Both require the same number of block encryption calls. Both are parallel in encryption and decryption. XTS is actually even faster in openssl implementation (openssl speed -evp aes-256-xts/gcm), not sure why.

Why even bother to use GCM instead of XTS?

• Sep 27, 2020 at 4:48

You're trying to compare authenticated encryption with disk encryption. GCM is used to solve 2 security problems at once: encryption and authentication. GCM is designed such that only someone knowing the key can modify ciphertext without raising alarms. This requires additional data to use as an authentication tag.

XTS, on the other hand, only partially hold this property. The benefit of XTS, however, is you don't need to store additional data for an authentication tag. XTS also has (some) resistance to tampering, since any change made to the ciphertext yields random and meaningless plaintext. However, this is not considered sufficient for authentication, since an attacker can still make changes without the changes being noticed. This is undesirable in any case where an attacker may intercept encrypted communication (ex. network protocols).

For full-disk encryption (FDE) authenticated encryption becomes impractical, since you would need to store a lot of extra data to verify integrity (with a mode like GCM). Unless you have so much disk space you don't mind losing half of it, this isn't a reasonable option. You could also store a separate hash (HMAC) but this still requires reading the entire contents of the disk to verify (which takes a long time), and will likely cause the hashes to mismatch simply due to normal wear and tear on the drive... Effectively creating a game of Russian Roulette; except instead of getting shot you lose data.

As such, unauthenticated encryption becomes the only rational way to encrypt an entire drive. Since an attacker cannot control the result of changes in XTS it's better than modes like CBC (where an attacker can rewrite the drive to whatever they want simply by being decently clever) or CTR (where cleverness isn't even a prerequisite to tamper with data), and XTS isn't vulnerable to statistical analysis like ECB. Therefore it's a not-ridiculous trade-off for cases where authentication can't be reasonably performed.

• An authentication is a separate step in GCM and I see no reason why the same authenticating (encrypted) checksum can not be appended to ciphertext produced with XTS as well. In encryption it is always better than GCM, right? No need in unique initialization vector.
– ZAB
Sep 26, 2020 at 22:40
• @ZAB: the authentication tag in GCM doesn't work if you don't use unique nonces, hence if you extend XTS to include GMAC-tags, you'll have to include nonces. You could go to a nonce-less integrity tag (e.g. HMAC or KMAC), however that'd loss all the performance advantages you were looking for Sep 26, 2020 at 22:41
• @poncho if you mean an initial value for the chain of multiplications then it can be made from plaintext or the counter as well, if I understand correctly the common name for this techniques is GCM-SIV. Why it can't be used for XTS? Well, the simple original question become a more difficult one, how to add authentication to XTS or if GCM-SIV itself suitable for disk encryption. A rather pointless question actually, it can only save some space and avoid the use of random generator for IV.
– ZAB
Sep 27, 2020 at 1:56
• GCM is effectively CTR + auth. If you visit the wikipedia page you'll see GCM encrypts only the counter, then XORs the plaintext (like CTR does). Then it adds the auth tag. XTS may be faster than GCM but it's not faster than CTR; and once you add the auth tag XTS will become slower than GCM. Sep 27, 2020 at 2:26
• Also, I don't like the name Galois/XTS (GXTS). It's cumbersome to explain to someone what Galois XOR-Encrypt-XOR with cipherText Stealing is. Sep 27, 2020 at 2:28