File Encryption issue

NTFSD
1

Hi all!

I am writing the FS encryption filter driver that encrypts/decrypts Paging
IO.

The encryption algorithm uses 16 bytes blocks. If the file size is 155
bytes, for example, that is not a multiplication

of 16, the following issue occurred:

  1. When the file is created, 4K buffer is sent for writing, the buffer
    contains zeros starting from 155 bytes offset. The driver encrypts 4K buffer

and forwards it to the FS.

  1. When I am trying to read the file (first time after reboot), 4K
    buffer is sent, but the returned buffer size is 155
    (Irp->IoStatus.Information = 155), so the driver

cannot decrypt it.

What can I do in this case?

Thanks,

Dani

2

Use common sense.
You’re not using ECB or CBC are you?? (Even CTS is not good for
random file I/O)

Dani Polovets wrote:

Hi all!

I am writing the FS encryption filter driver that encrypts/decrypts
Paging
IO.

The encryption algorithm uses 16 bytes blocks. If the file size is 155

bytes, for example, that is not a multiplication

of 16, the following issue occurred:

  1. When the file is created, 4K buffer is sent for writing, the
    buffer
    contains zeros starting from 155 bytes offset. The driver encrypts 4K
    buffer

and forwards it to the FS.

  1. When I am trying to read the file (first time after reboot),
    4K
    buffer is sent, but the returned buffer size is 155
    (Irp->IoStatus.Information = 155), so the driver

cannot decrypt it.

What can I do in this case?

–
Kind regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.

3

It seems to me that the right solution is to encrypt the buffer until
ValidDataLength.
Is it correct?

I saw the following in the “Filesize in paging I/O paths?” thread:
“There is one more complication related to paging IO. NTFS supports
persistent Valid Data Length. It allows NTFS to implement some optimization
and truncate Paging IO write based on current Valid data length instead of
EOF. So if you encrypt data between valid data length and EOF (which is all
0’s), subsequent read will return 0’s instead of encrypted 0’s.
Paging IO may or may not extend Valid data length depending on TopLevelIrp,
this optimization is applied only to requests that do not extend Valid Data
Length.”
Let’s look at the following example:
FileSize=1024, ValidDataLength=50, write is sent to the offset 550
(ValidDataLength becomes 550).
Will the data between old and new ValidDataLength be zeroed before this
write?

Thanks,
Dani

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
Sent: Wednesday, June 27, 2007 12:35 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] File Encryption issue

Use common sense.
You’re not using ECB or CBC are you?? (Even CTS is not good for
random file I/O)

Dani Polovets wrote:

Hi all!

I am writing the FS encryption filter driver that encrypts/decrypts
Paging
IO.

The encryption algorithm uses 16 bytes blocks. If the file size is 155

bytes, for example, that is not a multiplication

of 16, the following issue occurred:

  1. When the file is created, 4K buffer is sent for writing, the
    buffer
    contains zeros starting from 155 bytes offset. The driver encrypts 4K
    buffer

and forwards it to the FS.

  1. When I am trying to read the file (first time after reboot),
    4K
    buffer is sent, but the returned buffer size is 155
    (Irp->IoStatus.Information = 155), so the driver

cannot decrypt it.

What can I do in this case?

–
Kind regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.

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

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