NTFS Compressed File Problem in on-the-fly encryption

Hi, Everyone.
In My Last Post, Tony Mason said NTFS sparse file and compressed file are a bit problematic.
Can someone tell me what is the problem with sparse file and compressed file when developing an encryption filter driver?
I did some research. I create a comressed file which filesize is 0x2004, In explorer FileSize is 0x2004 and AllocationSize is 4K which is smaller than filesize. In my filter driver, FCB.FileSize of this file is 0x2004, FCB.ValidDataLength is 0x2004, FCB.AllocationSize is 64K.
so I think the sparse and compressed file work is processed in NTFS, and we don’t need to do some extra work in filter drivers for sparse and compressed file.Can some point out my error?

> Can someone tell me what is the problem with sparse file and compressed

file when developing an encryption filter driver?

Sparse files:

In order to not allow any data to escape you have to compress the sparse
regions - otherwise an unprivileged (to your keys) application can inspect
the file and have knowledge of the contents of large chunk of the file
(albeit that they are zero). Consider a file with 2Tb of sparseness and 1Gb
of encrypted data: an unprivileged attacker has immediate access to 99.9% of
the content of the file.

Compressed files:

If your encryption is good there will be no benefit to compressing an
encrypted file. To put it another way - if you can compress an encrypted
file then your encryption is broken. So there is no benefit. Also by
observation there is some sort of secret sauce between the cache manager and
NTFS when it comes to compression so you cannot “just” send paging IO down
to NTFS.

Rod

thank rod.

According to your words, for sparse files, the problem is that the empty area will be inspected by an unprivileged process.i think it isn’t a big problem, and i can deal with it.

for compressed file, what is some sort of secret sauce? can you give me a more detail information about this.

His point is that there is some unknown mechanism involved. Thus, you are asking him to describe something he’s telling you he doesn’t know.

Tony
OSR

> what is some sort of secret sauce? can you give me a more detail

information about this.

I don’t know what the precise problem is. I do know that NTFS uses the
cache to stage files prior to compression. Further I observe that if I
issue paging writes to a compressed stream under NTFS they are not written
in such a way that they can be sucessfully read at a later stage. From this
I infer that NTFS is using the cache manager in some unusual manner.

I didn’t have the time to bottom this out because, as I said at the top
there can be no value in compressing an encrypted file so it is better to
just deny something which doesn’t make sense (and then deal with the fallout
in WinHCK which is another story)

Thanks rod and tony!