Is AES in XTS mode insecure for data stream encryption?

Can anybody explain to me why AES in XTS mode is supposedly insecure for data stream encryption? I have been unable to find a clear explanation for this.

• Can you show us where you got this claim that it is insecure for data stream encryption? I guess that it kind of depends on how the data stream encryption is used within a protocol and to what end it is used. The blanket statement "AES in XTS mode is insecure for data stream encryption" may not be correct. – Maarten Bodewes Sep 16 '19 at 12:15
• @MaartenBodewes the exact statement (I think) was "AES in XTS mode is only suitable for whole disk encryption.". I shall try and find the reference... – Legorooj Sep 16 '19 at 12:26
• @MaartenBodewes Found the link after some digging - sockpuppet.org/blog/2014/04/30/you-dont-want-xts – Legorooj Sep 17 '19 at 0:00

From Ptaeck's site (here) (You linked this)

It’s complicated. It’s a wide-block tweakable mode built out of a narrow-block tweakable mode, it uses two keys unnecessarily, and it uses ciphertext stealing to handle variable-length inputs. Another way to say “complicated” is “hard to prove correct”.


This essentially means that it's easy to implement incorrectly, and might not be as secure as is thought in the first place.

It’s unclear what XTS’s goals are. It’s ECB-like. It can’t do a perfect job of providing privacy. It’s not authenticated. Attackers can rewrite plaintexts. It’s hard for a cryptographer to know what they’d be trying to prove. “behavesLikeXTS”? OK, and?


The lack of authentication is a big issue when not used for disk encryption: if an attacker can modify the ciphertext in transit that can't be detected by the recipient. The classic example of this would be rewriting a transaction's recipient or amount to get an attacker the money.

The wide-block-of-narrow-blocks property weakens XTS unnecessarily. As the disk rewrites a given sector, attackers can collect fine-grained (16 byte) ciphertexts. They get to manipulate ciphertexts surgically. It would have been possible to define a “native” wide-block tweakable cipher without that property, but that wouldn’t have been as performant.


The bit about ECB-like means that patterns in the plaintext data at certain scales are detectable in the ciphertext. That's bad, in some cases it can allow an attacker to determine the content of the plaintext.

This is also an issue due to the lack of authentication. The attacker can observe changes in the state of the ciphertext, and responses to their changes to the ciphertext. This makes attacks easier. Not necessarily practical, but not something you want to do if possible.

An ideal cipher should be computationally infeasible for an attacker to modify without detection (authenticated, integrity-preserving), should reveal nothing about the plaintext other than its size (confidential), and uniquely bound to a given origin (authentication). XTS provides no authentication, doesn't preserve integrity, and has some weaknesses in its confidentiality. It's the best we have for disk encryption without a specialized filesystem, but it's a terrible choice for anything without the constraints of full disk encryption on a general-purpose filesystem.

• Thanks, this is what I was hoping for. Would XTS-HMAC be less secure than CTR-HMAC then? – Legorooj Sep 17 '19 at 4:25
• Using a normal, naive method of applying XTS would still preserve the weaknesses in confidentiality. – Maarten Bodewes Sep 17 '19 at 10:39
• @MaartenBodewes thanks. – Legorooj Sep 19 '19 at 8:33