File sizes with encryption filter

NTFSD
1

Hi,

I’m working on Yet Another Encryption Filter. I am using a block cipher
and I need to modify the size of the file (essentially to round it up to
the next cipher block size multiple).

I’m performing the encryption/decryption in the Non-Cached I/O path and
I’m filtering all IRP_MJ_SET_INFORMATION, IRP_MJ_QUERY_INFORMATION and
IRP_MJ_DIRECTORY_CONTROL IRPs to properly “lie” about the file size.

The problem I’m having is that if, for instance, I open an encrypted
file with notepad, I see an extra pack of zeros at the end of the file
equal in number to the number of bytes I tacked on to the end of the file.

I’ve scoured the FAQ and the discussion list archives and I could not
find an answer to this problem.

Is this problem a result of the file system calling ccSetFileSizes()
directly?

Has anyone seen this problem and solved it?

Thanks,

Alex

P.S. I have seen recent discussions about using block ciphers in
“Counter-Mode” to avoid the padding requirement. This mode is not an
option for the requirements I have for various reasons. One of the
biggest reasons is that the method of encryption in “Counter-Mode” where
the data stream is XOR’d with the key stream provides absolutely no data
tampering resistance on its own (e.g. flip a bit in the ciphertext and
you’ve flipped the corresponding bit in cleartext). I really need to pad
that file.

2

You need to make sure that number of read bytes reported by IRP_MJ_READ or
FastIoRead is consistent with your “fake” size.

Alexei.

-----Original Message-----
From: Alex Coward [mailto:xxxxx@hotmail.com]
Sent: Tuesday, August 10, 2004 2:47 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] File sizes with encryption filter

Hi,

I’m working on Yet Another Encryption Filter. I am using a block cipher
and I need to modify the size of the file (essentially to round it up to
the next cipher block size multiple).

I’m performing the encryption/decryption in the Non-Cached I/O path and
I’m filtering all IRP_MJ_SET_INFORMATION, IRP_MJ_QUERY_INFORMATION and
IRP_MJ_DIRECTORY_CONTROL IRPs to properly “lie” about the file size.

The problem I’m having is that if, for instance, I open an encrypted
file with notepad, I see an extra pack of zeros at the end of the file
equal in number to the number of bytes I tacked on to the end of the file.

I’ve scoured the FAQ and the discussion list archives and I could not
find an answer to this problem.

Is this problem a result of the file system calling ccSetFileSizes()
directly?

Has anyone seen this problem and solved it?

Thanks,

Alex

P.S. I have seen recent discussions about using block ciphers in
“Counter-Mode” to avoid the padding requirement. This mode is not an
option for the requirements I have for various reasons. One of the
biggest reasons is that the method of encryption in “Counter-Mode” where
the data stream is XOR’d with the key stream provides absolutely no data
tampering resistance on its own (e.g. flip a bit in the ciphertext and
you’ve flipped the corresponding bit in cleartext). I really need to pad
that file.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@vmware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

I answered something like this recently. Do NOT change the file size just
for the encryption algorithm. If you have a fixed size header or trailer,
then you can change the size. No block encryption algorithm needs to change
the file size if implemented correctly. I do not mean use a simple XOR or
byte method on the last remainder of the file either.

“Alex Coward” wrote in message news:xxxxx@ntfsd…
> Hi,
>
> I’m working on Yet Another Encryption Filter. I am using a block cipher
> and I need to modify the size of the file (essentially to round it up to
> the next cipher block size multiple).
>
> I’m performing the encryption/decryption in the Non-Cached I/O path and
> I’m filtering all IRP_MJ_SET_INFORMATION, IRP_MJ_QUERY_INFORMATION and
> IRP_MJ_DIRECTORY_CONTROL IRPs to properly “lie” about the file size.
>
> The problem I’m having is that if, for instance, I open an encrypted
> file with notepad, I see an extra pack of zeros at the end of the file
> equal in number to the number of bytes I tacked on to the end of the file.
>
> I’ve scoured the FAQ and the discussion list archives and I could not
> find an answer to this problem.
>
> Is this problem a result of the file system calling ccSetFileSizes()
> directly?
>
> Has anyone seen this problem and solved it?
>
> Thanks,
>
> Alex
>
>
> P.S. I have seen recent discussions about using block ciphers in
> “Counter-Mode” to avoid the padding requirement. This mode is not an
> option for the requirements I have for various reasons. One of the
> biggest reasons is that the method of encryption in “Counter-Mode” where
> the data stream is XOR’d with the key stream provides absolutely no data
> tampering resistance on its own (e.g. flip a bit in the ciphertext and
> you’ve flipped the corresponding bit in cleartext). I really need to pad
> that file.
>
>
>
>
>
>

4

Alexei,

Thank you! Indeed that was the missing piece. After making sure to
properly lie about the file size in the fast paths (either cached
IRP_MJ_Xxx or Fast I/O) and properly handling STATUS_BUFFER_OVERFLOW
conditions in IRP_MJ_QUERY_INFORMATION everything worked like a charm.

Thanks again,

Alex

Alexei Jelvis wrote:

You need to make sure that number of read bytes reported by IRP_MJ_READ or
FastIoRead is consistent with your “fake” size.

Alexei.

-----Original Message-----
From: Alex Coward [mailto:xxxxx@hotmail.com]
Sent: Tuesday, August 10, 2004 2:47 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] File sizes with encryption filter

Hi,

I’m working on Yet Another Encryption Filter. I am using a block cipher
and I need to modify the size of the file (essentially to round it up to
the next cipher block size multiple).

I’m performing the encryption/decryption in the Non-Cached I/O path and
I’m filtering all IRP_MJ_SET_INFORMATION, IRP_MJ_QUERY_INFORMATION and
IRP_MJ_DIRECTORY_CONTROL IRPs to properly “lie” about the file size.

The problem I’m having is that if, for instance, I open an encrypted
file with notepad, I see an extra pack of zeros at the end of the file
equal in number to the number of bytes I tacked on to the end of the file.

I’ve scoured the FAQ and the discussion list archives and I could not
find an answer to this problem.

Is this problem a result of the file system calling ccSetFileSizes()
directly?

Has anyone seen this problem and solved it?

Thanks,

Alex

P.S. I have seen recent discussions about using block ciphers in
“Counter-Mode” to avoid the padding requirement. This mode is not an
option for the requirements I have for various reasons. One of the
biggest reasons is that the method of encryption in “Counter-Mode” where
the data stream is XOR’d with the key stream provides absolutely no data
tampering resistance on its own (e.g. flip a bit in the ciphertext and
you’ve flipped the corresponding bit in cleartext). I really need to pad
that file.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@vmware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com