paging IO and 192-bit (or any non-aligned on page size) encryption

NTFSD
1

Hi, all!

All of us knows how important to support paging IO with minimal efforts
to don’t reduce whole OS perfomance
By this reasons in the encryption filters usually uses page size-aligned
security algorithms like 128- or 256-bit AES, twofish, blowfish, etc.
But what about 3DES (triple-DES) which is 192-bit and has inner block
size 3*8-24 byte (thus we’ve got problems with doing transparent
encryption/decryption paging IO - 4096/24 not divided without
remainder).

So, to properly encypt/decrypt headers/trailers of each 4K (usually)
page, we have to read/write adjacent 0-2 pages (prev & next, if exists),
but this leads significant overheads during paging IO (roll our own
subrequests, etc.), it seems to me. Is there another ways to solve this?

I don’t know, but may be there is solution to align 192-bit security
algorithm to the page size boundary (using some encryption mode CBC,…
don’t remember)?

Who faced this problem before or/and knows possible solution, please,
share it with me

Reg?rds,
Valery

2

Hi,

I guess one way to do this (and I believe this was related to me by David J. Craig [xxxxx@yoshimuni.com] - errors mine) is to handle the tail of the page by double-encrypting the last few bytes before the tail. The algorithm is to do your regular encryption on the (PageSize div BlockSize) blocks, then handle the last BlockSize bytes by encrypting them in a separate pass. On decryption, you reverse the process by decrypting the trailing BlockSize bytes first, then do the page from start to end.
This does however beg a question for me: is it in general safe to handle the last page of a file as a full page or sector, and encrypt it as such, irrespective of the write length? I guess the answer may vary between FSDs, and even for different blocksizes with the same FSD?
If this isn’t safe, then there’s another boundary case which occurs when the entire length of the file is less than the BlockSize. This is somewhat more difficult to solve since you need extra storage of up to (BlockSize - 1) bytes, in order to be able to store the full encrypted block.

Siggi

-----Original Message-----
From: Valery Boronin [mailto:xxxxx@gorodok.net]
Sent: Tuesday, July 08, 2003 1:15 AM
To: File Systems Developers
Subject: [ntfsd] paging IO and 192-bit (or any non-aligned on page size) encryption

Hi, all!

All of us knows how important to support paging IO with minimal efforts to don’t reduce whole OS perfomance
By this reasons in the encryption filters usually uses page size-aligned security algorithms like 128- or 256-bit AES, twofish, blowfish, etc. But what about 3DES (triple-DES) which is 192-bit and has inner block size 3*8-24 byte (thus we’ve got problems with doing transparent encryption/decryption paging IO - 4096/24 not divided without remainder).

So, to properly encypt/decrypt headers/trailers of each 4K (usually) page, we have to read/write adjacent 0-2 pages (prev & next, if exists), but this leads significant overheads during paging IO (roll our own subrequests, etc.), it seems to me. Is there another ways to solve this?

I don’t know, but may be there is solution to align 192-bit security algorithm to the page size boundary (using some encryption mode CBC,… don’t remember)?

Who faced this problem before or/and knows possible solution, please, share it with me

Reg?rds,
Valery

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

3

Thanks Dejan and Siggi!

Well, about Dejan’s answer: I know how to manipulate additional pages
during paging IO but my original question was how to avoid it (mainly).
Moreover for RDR files I’ve already use similar technique. But I’ve hope
to get answer like Siggi: looks like it’s the way! I want to hear about
security in this case also.

Also, yesterday I’ve came to the padding solution but it requires per
file keeping these paddings. Not very good for us now - by reason Siggi
also noticed at the end.

So, last unclear for me here is why Dejan tell me that using of (CTR,
CFB, OFB, and even CTS…) requires additional page manipulation
efforts? Why we can’t do encryption on a 4K basis - each page
independently, but with using pointed out encryption mode on the stream
data for each page? I.e. use page size div block size as usual and left
data with previous block(s), actually?

And what’s exact name for such encryption mode in the list of (CTR, CFB,
OFB, and even CTS) ? :slight_smile:

Reg?rds,
Valery Boronin

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Sigurdur
Asgeirsson
Sent: Wednesday, July 09, 2003 7:44 AM
To: File Systems Developers
Subject: [ntfsd] RE: paging IO and 192-bit (or any non-aligned on page
size) encryption

Hi,

I guess one way to do this (and I believe this was related to me by
David J. Craig [xxxxx@yoshimuni.com] - errors mine) is to handle the
tail of the page by double-encrypting the last few bytes before the
tail. The algorithm is to do your regular encryption on the (PageSize
div BlockSize) blocks, then handle the last BlockSize bytes by
encrypting them in a separate pass. On decryption, you reverse the
process by decrypting the trailing BlockSize bytes first, then do the
page from start to end. This does however beg a question for me: is it
in general safe to handle the last page of a file as a full page or
sector, and encrypt it as such, irrespective of the write length? I
guess the answer may vary between FSDs, and even for different
blocksizes with the same FSD? If this isn’t safe, then there’s another
boundary case which occurs when the entire length of the file is less
than the BlockSize. This is somewhat more difficult to solve since you
need extra storage of up to (BlockSize - 1) bytes, in order to be able
to store the full encrypted block.

Siggi

-----Original Message-----
From: Valery Boronin [mailto:xxxxx@gorodok.net]
Sent: Tuesday, July 08, 2003 1:15 AM
To: File Systems Developers
Subject: [ntfsd] paging IO and 192-bit (or any non-aligned on page size)
encryption

Hi, all!

All of us knows how important to support paging IO with minimal efforts
to don’t reduce whole OS perfomance By this reasons in the encryption
filters usually uses page size-aligned security algorithms like 128- or
256-bit AES, twofish, blowfish, etc. But what about 3DES (triple-DES)
which is 192-bit and has inner block size 3*8-24 byte (thus we’ve got
problems with doing transparent encryption/decryption paging IO -
4096/24 not divided without remainder).

So, to properly encypt/decrypt headers/trailers of each 4K (usually)
page, we have to read/write adjacent 0-2 pages (prev & next, if exists),
but this leads significant overheads during paging IO (roll our own
subrequests, etc.), it seems to me. Is there another ways to solve this?

I don’t know, but may be there is solution to align 192-bit security
algorithm to the page size boundary (using some encryption mode CBC,…
don’t remember)?

Who faced this problem before or/and knows possible solution, please,
share it with me

Reg?rds,
Valery

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

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

4

> This does however beg a question for me: is it in general safe to
handle the last page of a

file as a full page or sector, and encrypt it as such, irrespective
of the write length? I guess

The last page or sector in the file is always padded with zeroes.

Max

5

Hi Max,

you’re saying that the memory manager will pass you memory filled with
zeros past the file’s EOF to the paging write? I’m sure this is true,
but it’s more or less unrelated to my question, which may have been
poorly worded.
My question is this: what happens if your filter modifies the portion of
the page that sticks out past EOF, before passing the write down to the
FSD?
See, I’ve heard of encrypting filters that make use of the fact that -
at least some - FSDs write the entire page passed in to a paging write
to disk, irrespective of the write length (or at least up to the next
sector boundary), and trust that they’ll eventually read the (upto
BlockSize - 1) bytes *past* EOF back unmolested to reverse the
encryption.
If it’s safe to trust to this behaviour, that FSDs are Sector or Page
granular on paging reads and writes, then you can assume in your filter
that, irrespective of the file’s EOF (as long as it’s >0), you’ll have
access to no less than SectorSize bytes of storage.

Siggi

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, July 08, 2003 11:53 PM
To: File Systems Developers
Subject: [ntfsd] RE: paging IO and 192-bit (or any non-aligned on page
size) encryption

This does however beg a question for me: is it in general safe to
handle the last page of a
file as a full page or sector, and encrypt it as such, irrespective
of the write length? I guess

The last page or sector in the file is always padded with zeroes.

Max

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

6

The EOF is the EOF. Don’t even think about using the slack space. It is a
very bad idea and your encryption algorithm will fail if something happens
to the slack space. You have already been given an algorithm for handling
non-mod n blocks. If you can’t figure how to implement it, pay someone or
just use a simple XOR on that remaining piece. If your algorithm isn’t
evenly divisible into 512 try another algorithm. Stream ciphers are not as
secure, I think, but they work at the byte level. I thought you were about
ready to release the product. Say hello to Harminder.

“Sigurdur Asgeirsson” wrote in message
news:xxxxx@ntfsd…

Hi Max,

you’re saying that the memory manager will pass you memory filled with
zeros past the file’s EOF to the paging write? I’m sure this is true,
but it’s more or less unrelated to my question, which may have been
poorly worded.
My question is this: what happens if your filter modifies the portion of
the page that sticks out past EOF, before passing the write down to the
FSD?
See, I’ve heard of encrypting filters that make use of the fact that -
at least some - FSDs write the entire page passed in to a paging write
to disk, irrespective of the write length (or at least up to the next
sector boundary), and trust that they’ll eventually read the (upto
BlockSize - 1) bytes past EOF back unmolested to reverse the
encryption.
If it’s safe to trust to this behaviour, that FSDs are Sector or Page
granular on paging reads and writes, then you can assume in your filter
that, irrespective of the file’s EOF (as long as it’s >0), you’ll have
access to no less than SectorSize bytes of storage.

Siggi

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, July 08, 2003 11:53 PM
To: File Systems Developers
Subject: [ntfsd] RE: paging IO and 192-bit (or any non-aligned on page
size) encryption

> This does however beg a question for me: is it in general safe to
handle the last page of a
>file as a full page or sector, and encrypt it as such, irrespective
of the write length? I guess

The last page or sector in the file is always padded with zeroes.

Max

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

7

Hey there David,

and thanks for the tips - I’ll be sure to hire someone if ever we come
across the slightest bit of implementation difficulty :).
However, all of this is just idle speculation and curiosity on my part
that arose due to the original question. Personally I’d never think of
using the slack space in a product.

Siggi

-----Original Message-----
From: David J. Craig [mailto:xxxxx@yoshimuni.com]
Sent: Wednesday, July 09, 2003 2:08 PM
To: File Systems Developers
Subject: [ntfsd] Re: paging IO and 192-bit (or any non-aligned on page
size) encryption

The EOF is the EOF. Don’t even think about using the slack space. It
is a very bad idea and your encryption algorithm will fail if something
happens to the slack space. You have already been given an algorithm
for handling non-mod n blocks. If you can’t figure how to implement it,
pay someone or just use a simple XOR on that remaining piece. If your
algorithm isn’t evenly divisible into 512 try another algorithm. Stream
ciphers are not as secure, I think, but they work at the byte level. I
thought you were about ready to release the product. Say hello to
Harminder.

“Sigurdur Asgeirsson” wrote in message
news:xxxxx@ntfsd…

Hi Max,

you’re saying that the memory manager will pass you memory filled with
zeros past the file’s EOF to the paging write? I’m sure this is true,
but it’s more or less unrelated to my question, which may have been
poorly worded. My question is this: what happens if your filter modifies
the portion of the page that sticks out past EOF, before passing the
write down to the FSD? See, I’ve heard of encrypting filters that make
use of the fact that - at least some - FSDs write the entire page passed
in to a paging write to disk, irrespective of the write length (or at
least up to the next sector boundary), and trust that they’ll eventually
read the (upto BlockSize - 1) bytes past EOF back unmolested to
reverse the encryption. If it’s safe to trust to this behaviour, that
FSDs are Sector or Page granular on paging reads and writes, then you
can assume in your filter that, irrespective of the file’s EOF (as long
as it’s >0), you’ll have access to no less than SectorSize bytes of
storage.

Siggi

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, July 08, 2003 11:53 PM
To: File Systems Developers
Subject: [ntfsd] RE: paging IO and 192-bit (or any non-aligned on page
size) encryption

> This does however beg a question for me: is it in general safe to
handle the last page of a
>file as a full page or sector, and encrypt it as such, irrespective
of the write length? I guess

The last page or sector in the file is always padded with zeroes.

Max

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

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

8

> If it’s safe to trust to this behaviour, that FSDs are Sector or
Page

granular on paging reads and writes, then you can assume in your
filter

FSDs are sector-granular on all noncached IO, including paging IO.

For a last page in a file, the FSD reads only the number of sectors
allocated in the file, and either zeroes the rest of the page, or sets
Irp->IoStatus.Information to < PAGE_SIZE, in which case Mm will zero
the page’s tail.

Max

9

> I can tell, on writes, it will NOT zero the slack space before
writing

it out, but on reads, it will.

So, a cache miss on the last page will result in slack space zeroed in
read path.
Then a lazy write of this same page (if it was dirtied) will write the
zeroed slack space.

The result is FASTFAT keeping slack space zeroed.

Max