Re[2]: Best choice for encryption in file system level

The main issue that Don is pointing out that introduces complexities is
when you attempt to change the file size. This results in your filter
having to fake the size to the caller above. For example, if you use an
encryption algorithm that has a 16 byte cypher block size then
everything you write to the underlying file system will be aligned to 16
bytes but the actual file size may be 17 bytes.

That said, if you want to do something simple like this, use XOR or some
algorithm that has a single byte alignment. You will only deal with
non-cached and paging (which is non-cached) IO on both read and write
sides. Get that in place and go from there.

Pete


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com http:</http:>
866.263.9295

------ Original Message ------
From: “Bekir Karul”
To: “Windows File Systems Devs Interest List”
Sent: 3/25/2017 1:52:31 AM
Subject: Re: [ntfsd] Best choice for encryption in file system level

>Thank you Scott for your reply.
>I hope it will be fun.
>
>
>24.03.2017, 20:41, “Scott Noone” :
>>If you just want to play around, give yourself the following
>>rules/restrictions:
>>
>>1. I shall not change the size of the file
>>
>>2. All filters and applications above my filter only ever see the
>>decrypted
>>data (i.e. no mixed policy where some applications see decrypted data
>>and
>>some applications see encrypted data).
>>
>>You’ll have an amusing time sorting through the problems with the
>>above. If
>>you deviate from either you’ll go right off a cliff.
>>
>>-scott
>>OSR
>>@OSRDrivers
>>
>>“Don Burn” wrote in message news:xxxxx@ntfsd…
>>
>>You can do it in a mini-filter. As I stated, things get hairy when you
>>change the size of the file or the size of the data in the file. Make
>>sure you see all the reads and writes, since file caching will need to
>>be
>>addressed.
>>
>>
>>Don Burn
>>Windows Driver Consulting
>>Website: http://www.windrvr.com http:</http:>
>>
>>
>>
>>
>>-----Original Message-----
>>From: xxxxx@lists.osr.com
>>[mailto:xxxxx@lists.osr.com] On Behalf Of
>>xxxxx@yandex.com
>>Sent: Friday, March 24, 2017 11:17 AM
>>To: Windows File Systems Devs Interest List
>>Subject: RE:[ntfsd] Best choice for encryption in file system level
>>
>>Thank you Don for information about OSR’s kit. It make me understand
>>how
>>hard it can be.
>>
>>For my situation, the only process will read and write to file is
>>mine. So
>>it is not important about who read it.
>>
>>And, I think it will be no problem with using simple encryption
>>scheme. By
>>the way, I do not have to make it a encyption driver. As I said, it is
>>just
>>a idea. Let say, I can just use it for replace a word “kotoro” with
>>“kamato”
>>when writing to disk. And replace “kamato” with “kotoro” when reading
>>from
>>disk. I just trying to do and learn, that’s all.
>>
>>So, I assume it is possible from mini-filter?
>>If you approve, then can you please point me about the edge sides
>>should I
>>keep in mind?
>>
>>Best regards
>>
>>
>>
>>—
>>NTFSD is sponsored by OSR
>>
>>
>>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>>software
>>drivers!
>>Details at http:
>>
>>To unsubscribe, visit the List Server section of OSR Online at
>>http:
>>
>>
>>—
>>NTFSD is sponsored by OSR
>>
>>
>>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>>software drivers!
>>Details at http:
>>
>>To unsubscribe, visit the List Server section of OSR Online at
>>http:
>>
>— NTFSD is sponsored by OSR MONTHLY seminars on crash dump analysis,
>WDF, Windows internals and software drivers! Details at To unsubscribe,
>visit the List Server section of OSR Online at</http:></http:></http:></http:>

Hello Pete,

Thank you very much for you informative reply. I get the idea how things gets complicated just because file size issue.

So, if I didn’t misunderstand, I can use some algorithm which uses one byte alignment. Thats way file size always be the same.

Hmm, if you have time, can you please light it up a bit why I need to use non-cached I/O? What can be goes wrong if I uses cached ones too? Is this simply because cached I/O does not written into disk immediately?

Best regards

Although it is volume based, it may be worth reviewing TrueCrypt.

https://github.com/FreeApophis/TrueCrypt

On Sat, Mar 25, 2017 at 9:16 AM wrote:

> Hello Pete,
>
> Thank you very much for you informative reply. I get the idea how things
> gets complicated just because file size issue.
>
> So, if I didn’t misunderstand, I can use some algorithm which uses one
> byte alignment. Thats way file size always be the same.
>
> Hmm, if you have time, can you please light it up a bit why I need to use
> non-cached I/O? What can be goes wrong if I uses cached ones too? Is this
> simply because cached I/O does not written into disk immediately?
>
> Best regards
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

The “easiest” way to describe this is by thinking first about memory mapped I/O. I’m going to hand wave a bit here and I suggest you play around with FileTest and watch the behavior yourself (building your own copy of FASTFAT helps).

If an application memory maps a file, the memory manager will send non-cached paging I/O to read in the data to back the memory mapping. This happens on demand and the data stays in memory (effectively) for as long as the memory Manager feels like. Your filter sees this I/O, you decrypt as necessary. So far so good…

The fun then happens if another (or the same) application comes along and does a cached read. The file system calls the Cache Manager to deal with the read, and the Cache Manager memory maps the file. This memory mapping uses the same memory as the previous memory mapping from the application, no point in reading the data back into memory.

The Cache Manager then copies the data into the user buffer and the cached read completes. There is no paging I/O as the data was already in memory. If you decrypt the cached read, you’ll decrypt an already decrypted buffer.

You get other problems if this happens in the opposite order (i.e. cached read followed by a memory mapping). This is the crux of the “my filter works with everything but Notepad!” problem as Notepad reads using memory mapped I/O.

-scott
OSR
@OSRDrivers

Thank you Jamey for your suggestion but it does not make sense for me, because I asked this question just because I’m trying to learn mini-filter drivers.

Scoot, it is clear why problems apper with memory mapped files now. Thank you very much.

So, I guess I understand why encyption drivers gets a nightmare when trying to implement it file system wide range.

So, as far as I can understand, it will be okay with my point of view. I only encypt/change the file which is created by my user mode program, lets say it is something like license file. (Of course, I know I can do this from user-mode, but I’m learning mini-filters). I’ll catch that I/O operation (by testing process name and file name) in pre-write for encyption with one byte alignment algorithm, and I’ll decrypt it in post-read routine, right? And of course I’ll use non-cached I/O when writing/reading to that file (I guess by using both FILE_FLAG_WRITE_THROUGH and FILE_FLAG_NO_BUFFERING flag in user-mode).

Please correct me if I’m wrong, and thanks to all who replied my question with patience.

Best regards