I know that content compression can cause SSL to be vulnerable to the CRIME attack, via changes in the content length when injected plaintext matches existing content. Does this principle carry over to NTFS file compression on volumes that are encrypted via tools like BitLocker or TrueCrypt?
![](../../users/profiles/414.webp)
- 50,912
- 13
- 120
- 179
![](../../users/profiles/5400.webp)
- 132,208
- 43
- 298
- 379
-
Padding (required for CBC mode) would disrupt the leakage of information through the size of the ciphertext. – Cristian Dobre Jan 09 '13 at 19:43
-
1Padding can usually be accounted for, by _phasing_. If the file has size _n_ where _n_ is a multiple of 16 (the block size), then padded size will typically be _n+16_, whereas with size _n-1_ the passed size will be _n_. It is up to the attacker to alter the data he injects so that he gets the compressed length on such a "threshold". This makes his task harder, but not insurmountably harder. – Thomas Pornin Jan 09 '13 at 20:25
-
@CristianDobre Disk encryption typically does not use CBC. For example, TrueCrypt uses [XTS mode](http://en.wikipedia.org/wiki/XEX-TCB-CTS#XEX-based_tweaked-codebook_mode_with_ciphertext_stealing_.28XTS.29). – Polynomial Jan 09 '13 at 20:30
1 Answers
According to this blog message, NTFS compression is per-file: it can be activated on each file individually, or on the whole volume, but even in the latter case, each file is compressed independently of the others. This makes sense because data redundancies are often intra-files, not inter-files, and doing otherwise would be quite hard anyway.
CRIME-like attacks work when the attacker can insert his own data which is compressed along with data that the attacker wishes to guess (in the case of CRIME, the secret data was an HTTP Cookie in a request where the attacker gets to choose the target path). To transfer that to NTFS compression, you must imagine a system with files that the attacker cannot read, containing data which is interesting to the attacker, but such that the attacker can insert some contents of its own in the file.
Also, CRIME-like attacks require that the attacker can observe the compressed size. I am not sure that Windows offers an access to that information, and, crucially, can yield this information for files which the attacker cannot read. To some extent, the attacker can observe the free space total count on the volume, and thus guess the efficiency of compression on a single write, but with a high granularity (that of a cluster, i.e. a few kilobytes). If the compressed size of the target files can be observed with byte granularity by the attacker, then I deem CRIME-like attacks a plausible thing.
For instance, imagine a file containing unencrypted user passwords, and user-chosen "display names". By registering new users with crafted names, the attacker would try to exploit similarities between the crafted names, and the passwords of the other users.
![](../../users/profiles/71850.webp)
- 2,235
- 6
- 18
- 30
![](../../users/profiles/655.webp)
- 320,799
- 57
- 780
- 949