Hi,
I have scanned the FAQ and lists but didn’t see this but apologies if it has
been covered before.
Basically, I have written an encryption filter driver and the files have
headers. I want the headers to be invisible to user programs so I adjust the
size returned in all flavours of MJ_QUERY that return EOF information. When
the files are on NTFS partitions, it all works and I can read and write the
files. However, when the files are on a FAT partition, when I write (via
notepad for instance), I get a bugcheck (IRQL not less or equal). The
address being written is the same as the file size I return in the MJ_QUERY.
I know this is true because I tried forcing the size to a different value in
the debugger and sure enough, the faulting address changed as well.
The bug check does not occur during my processing of the MJ_WRITE but after
I return from it. If I take out the code that modifies the size in MJ_QUERY,
the problem goes away.
Before I start trawling through the FAT sources, I am hoping someone might
have an idea ?
Thanks & Regards,
Trevor Heartfield
A very complex thing full of issues. I would suggest to use sideband
information (some separate database) instead of the file headers.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Trevor Heartfield”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Thursday, August 05, 2004 5:54 PM
Subject: [ntfsd] Bug Check when modifying IRP_MJ_QUERY_INFORMATION for file on
FAT partition
> Hi,
> I have scanned the FAQ and lists but didn’t see this but apologies if it has
> been covered before.
>
> Basically, I have written an encryption filter driver and the files have
> headers. I want the headers to be invisible to user programs so I adjust the
> size returned in all flavours of MJ_QUERY that return EOF information. When
> the files are on NTFS partitions, it all works and I can read and write the
> files. However, when the files are on a FAT partition, when I write (via
> notepad for instance), I get a bugcheck (IRQL not less or equal). The
> address being written is the same as the file size I return in the MJ_QUERY.
> I know this is true because I tried forcing the size to a different value in
> the debugger and sure enough, the faulting address changed as well.
>
> The bug check does not occur during my processing of the MJ_WRITE but after
> I return from it. If I take out the code that modifies the size in MJ_QUERY,
> the problem goes away.
>
> Before I start trawling through the FAT sources, I am hoping someone might
> have an idea ?
>
> Thanks & Regards,
> Trevor Heartfield
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> A very complex thing full of issues. I would suggest to use sideband
information (some separate database) instead of the file headers.
Or use a file tail. Separate database means that you
must ensure that the database stays up-to-date, which is
really not easy. Most encryption methods
(except the primitive ones) will round
the file size anyway, so you have to solve the file-size-
problems sooner or later.
L.
Why would they round the file size?? Especially non-primitive ones…
Most encryption methods (except the primitive ones) will round
the file size anyway, so you have to solve the file-size-
problems sooner or later.
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.
> Why would they round the file size?? Especially non-primitive ones…
For example, AES needs the data buffer to be rounded
up to 16-byte boundary, AES 256 needs the data to be rounded
up to 32-byte boundary.
If the file size is not multiplier of the required boundary,
it must be padded with zeros. However, the encrypted
zeros cannot be simply thrown away,
because the decryption of the file tail will not
give the same data as have been encrypted.
The data size will be the same only if you use something
as Caesar’s cipher (add +3 to every byte) or some sort
of XORing. The size will then be the same, but these
ciphers are good for children’s games only.
L.
> The data size will be the same only if you use something
as Caesar’s cipher (add +3 to every byte) or some sort
of XORing. The size will then be the same, but these
ciphers are good for children’s games only.
Really?
There are “stream ciphers” which use the stream of specially generated
pseudo-random bytes, where the generator is initialized by the cipher key. Then
the real data is XORed with this stream.
The decoder side must re-implement the same generator, prime it with the same
key, and XOR the ciphertext with the generator output once more.
From what I know, SSL uses exactly this method.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
For all you “encryption” people out there. There is no reason to always
use block ciphers (AES, 3DES, etc) in block cipher mode, every block
cipher is able to run in Counter-Mode, this makes a stream cipher from a
block cipher and is as secure as the algorithm in it’s block mode. Am
tired of people saying that they MUST pad a file when using a block
cipher, this just isnt required.
Regards
Ben Curley
Data Encryption Systems Ltd.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: 06 August 2004 15:23
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Bug Check when modifying IRP_MJ_QUERY_INFORMATION
for file on FAT partition
Why would they round the file size?? Especially non-primitive ones…
For example, AES needs the data buffer to be rounded
up to 16-byte boundary, AES 256 needs the data to be rounded
up to 32-byte boundary.
If the file size is not multiplier of the required boundary,
it must be padded with zeros. However, the encrypted
zeros cannot be simply thrown away,
because the decryption of the file tail will not
give the same data as have been encrypted.
The data size will be the same only if you use something
as Caesar’s cipher (add +3 to every byte) or some sort
of XORing. The size will then be the same, but these
ciphers are good for children’s games only.
L.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@des.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com
Why not take the last n bytes of the file - where n = cipher block size?
Encrypt this block after encrypting all previous blocks. Decrypt this block
before decrypting the block underlying part of that last block. Simple, no
file size changes, same security as the remainder of the file. If the file
is a modulus of the cipher block size, no special code path is required.
Been doing this for 15 years.
“Ben Curley” wrote in message news:xxxxx@ntfsd…
For all you “encryption” people out there. There is no reason to always
use block ciphers (AES, 3DES, etc) in block cipher mode, every block
cipher is able to run in Counter-Mode, this makes a stream cipher from a
block cipher and is as secure as the algorithm in it’s block mode. Am
tired of people saying that they MUST pad a file when using a block
cipher, this just isnt required.
Regards
Ben Curley
Data Encryption Systems Ltd.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: 06 August 2004 15:23
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Bug Check when modifying IRP_MJ_QUERY_INFORMATION
for file on FAT partition
> Why would they round the file size?? Especially non-primitive ones…
For example, AES needs the data buffer to be rounded
up to 16-byte boundary, AES 256 needs the data to be rounded
up to 32-byte boundary.
If the file size is not multiplier of the required boundary,
it must be padded with zeros. However, the encrypted
zeros cannot be simply thrown away,
because the decryption of the file tail will not
give the same data as have been encrypted.
The data size will be the same only if you use something
as Caesar’s cipher (add +3 to every byte) or some sort
of XORing. The size will then be the same, but these
ciphers are good for children’s games only.
L.
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@des.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com
If you do ciphering that way, any child skillful in mathematics will decipher it
in a matter of minutes. It’s just a matter of finding the algorithm…
What you’re referring to is the basic ciphering mode of a block cipher (such as
AES, Blowfish etc.) called ECB, which is unsecure. So other modes are used. Since
transparent encryption requires random access ciphering CTS mode is not possible
(same with OFB, CFB, CBC (this one is block based as well). So CTR is used - and CTR
does not require block rounding.
Agreed, CTR is not as secure as CTS, but it’s the only applicable mode for
transparent encryption.
I am no crypto guru (and I doubt anyone got that impression:-), but I know the
above for a fact as I’ve done encryption for government agencies and they used CTR
(strangely it seems not everyone calls this mode CTR (Counter Mode)).
For example, AES needs the data buffer to be rounded
up to 16-byte boundary, AES 256 needs the data to be rounded
up to 32-byte boundary.
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.
Stream ciphers as well as CFB, OFB and CTS mode of block ciphers have one
limitation - they require previous (or next) byte deciphered before “this” byte can
be deciphered. Therefore, imagine a database of 50 MB, where you need just the record
sitting at position “file size - record size” - all but one stream cipher (that I
know of) as well as CFB, OFB and CTS modes of block ciphers will decrypt (i.e. read
and then decrypt) the bytes 0 to “file size - record size” before giving back the
record.
There are “stream ciphers” which use the stream of specially generated
pseudo-random bytes, where the generator is initialized by the cipher key. Then the
real data is XORed with this stream.
The decoder side must re-implement the same generator, prime it with the same key,
and XOR the ciphertext with the generator output once more.
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.
Amen:-)
Am tired of people saying that they MUST pad a file when using a block cipher, this
just isnt required.
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.
Sorry, but stream ciphers (as opposed to block ciphers) are widely used,
since they do not require any data padding, and thus are very good for things
like SSL.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Dejan Maksimovic”
To: “Windows File Systems Devs Interest List”
Sent: Friday, August 06, 2004 9:02 PM
Subject: Re: [ntfsd] Bug Check when modifying IRP_MJ_QUERY_INFORMATION for file
on FAT partition
>
> If you do ciphering that way, any child skillful in mathematics will
decipher it
> in a matter of minutes. It’s just a matter of finding the algorithm…
Correct. That’s why they are used for stream appliances like SSL.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Dejan Maksimovic”
To: “Windows File Systems Devs Interest List”
Sent: Friday, August 06, 2004 9:06 PM
Subject: Re: [ntfsd] Bug Check when modifying IRP_MJ_QUERY_INFORMATION for file
on FAT partition
>
> Stream ciphers as well as CFB, OFB and CTS mode of block ciphers have one
> limitation - they require previous (or next) byte deciphered before “this”
byte can
> be deciphered. Therefore, imagine a database of 50 MB, where you need just
the record
> sitting at position “file size - record size” - all but one stream cipher
(that I
> know of) as well as CFB, OFB and CTS modes of block ciphers will decrypt
(i.e. read
> and then decrypt) the bytes 0 to “file size - record size” before giving back
the
> record.
>
> > There are “stream ciphers” which use the stream of specially generated
> > pseudo-random bytes, where the generator is initialized by the cipher key.
Then the
> > real data is XORed with this stream.
> >
> > The decoder side must re-implement the same generator, prime it with the
same key,
> > and XOR the ciphertext with the generator output once more.
>
> –
> Kind regards, Dejan M. MVP for DDK
> http://www.alfasp.com E-mail: xxxxx@alfasp.com
> Alfa Transparent File Encryptor - Transparent file encryption services.
> Alfa File Protector - File protection and hiding library for Win32
developers.
> Alfa File Monitor - File monitoring library for Win32 developers.
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Yes, but SSL does not require large amounts of data… files do.
“Maxim S. Shatskih” wrote:
Sorry, but stream ciphers (as opposed to block ciphers) are widely used, since
they do not require any data padding, and thus are very good for things like SSL.
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.
Interesting idea, but the volume of the data is not the real reason. SSL is
sequential by nature. Each character received is present when decryption is
being done, while mass storage may have random access where the beginning of
a file is not required for the current or any previous request. Both stream
and block ciphers are necessary with computers, but mass storage should be
block. If you create a file of 5GB of all zeroes, does each block repeat
the same encrypted data? If so, you need to add something to prevent
compromising the key. This stuff is rather easy, but proper implementation
should be done with some consulting from RSA or CounterPane.
Remember Netscape’s problems with SSL. It was the beginning of the end for
them and the domination of the browser market by IE. IE is trying to follow
Netscape’s example but in the security/privacy area, but I don’t know if it
will hurt them as much as it did Netscape. I use Mozilla since the
recommendation from NIST (?). I still have some sites that require IE,
though.
“Dejan Maksimovic” wrote in message news:xxxxx@ntfsd…
>
> Yes, but SSL does not require large amounts of data… files do.
>
> “Maxim S. Shatskih” wrote:
>
> > Sorry, but stream ciphers (as opposed to block ciphers) are widely
used, since
> > they do not require any data padding, and thus are very good for things
like SSL.
>
> –
> Kind regards, Dejan M. MVP for DDK
> http://www.alfasp.com E-mail: xxxxx@alfasp.com
> Alfa Transparent File Encryptor - Transparent file encryption services.
> Alfa File Protector - File protection and hiding library for Win32
developers.
> Alfa File Monitor - File monitoring library for Win32 developers.
>
>
>
Forgive the mumbling in my previous e-mail, I was sleepy:-) Yes, the random
access nature is the major PITA.
“David J. Craig” wrote:
> Interesting idea, but the volume of the data is not the real reason. SSL is
> sequential by nature. Each character received is present when decryption is
> being done, while mass storage may have random access where the beginning of
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.
> block. If you create a file of 5GB of all zeroes, does each block repeat
the same encrypted data? If so, you need to add something to prevent
compromising the key.
XOR the data with the file block number (as salt) before encrypting.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
This is a disk filter he said. You can use the sector address and maybe
hash it to a more random value then use it as the salt. In some ways doing
an encryption file system filter is easier as you can use file offset and
its block size modulo as the salt too. I just think a simple increasing
value is far too easy to reverse engineer. That is why there are companies
that do this type of consulting. Remember that DES is now rather easy to
break, especially when you consider that 1000 CPU systems are available.
Even small RSA key lengths are now possible to break and even larger key
lengths will be possible in the future. If someone finds a method to do
large number factoring without the current brute force methods, RSA will be
obsolete. Who knows what the ‘no such agency’ has hidden.
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntfsd…
> > block. If you create a file of 5GB of all zeroes, does each block
repeat
> > the same encrypted data? If so, you need to add something to prevent
> > compromising the key.
>
> XOR the data with the file block number (as salt) before encrypting.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
Security must not depend on reverse engineering difficulty. It is security through obscurity. Using plain sector numbers is equally secure. Well, I’m sure you know it. Using something more random doesn’t cause any harm; it just can’t be taken as more secure solution.
Another possibility is to use (randomised) sector number as encryption initialization vector.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http:://www.upek.com]
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of David J. Craig[SMTP:xxxxx@yoshimuni.com]
Reply To: Windows File Systems Devs Interest List
Sent: Saturday, August 07, 2004 2:24 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Re:Bug Check when modifying IRP_MJ_QUERY_INFORMATION for file on FAT partition
This is a disk filter he said. You can use the sector address and maybe
hash it to a more random value then use it as the salt. In some ways doing
an encryption file system filter is easier as you can use file offset and
its block size modulo as the salt too. I just think a simple increasing
value is far too easy to reverse engineer. That is why there are companies
that do this type of consulting. Remember that DES is now rather easy to
break, especially when you consider that 1000 CPU systems are available.
Even small RSA key lengths are now possible to break and even larger key
lengths will be possible in the future. If someone finds a method to do
large number factoring without the current brute force methods, RSA will be
obsolete. Who knows what the ‘no such agency’ has hidden.
“Maxim S. Shatskih” wrote in message
> news:xxxxx@ntfsd…
> > > block. If you create a file of 5GB of all zeroes, does each block
> repeat
> > > the same encrypted data? If so, you need to add something to prevent
> > > compromising the key.
> >
> > XOR the data with the file block number (as salt) before encrypting.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
>
>
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@upek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Yes, I agree, but my concern was that using the sector number or sector
number of the first sector of the block if block size is larger than sector
size would lead to very few bits of change for each block. The size of that
salt might be 64 bits so the first part of each block might be the same
unless the encryption algorithm propagates backwards in the block as well as
forward. I am just paranoid and pretty good at implementing encryption but
I am not nor do I ever want to be a cryptographer. For speed many
encryption algorithms work in a smaller sub-block such as DES that works on
8 byte blocks with the 56 bit key. Today the processors are much faster and
many encryption algorithms don’t impose as much overhead as DES used to on a
4.77Mhz 8088.
I see so many questions about encryption - either in volume filters or file
system filters. Most don’t indicate any understanding of cryptography and
would probably just be an ‘appearance’ of security. How many people know
that one quick test of a good encryption algorithm is just using a good
compression algorithm (or several) and see if the data can be compressed?
If you try ZIP or maybe a ZIP type with a 2MB window, and several lossless
audio, video and data compression algorithms and your compression ratio is
less than 3%, you have a good start. Have it verified by a good company or
use a good standard algorithm and have the implementation verified. I want
a good encryption utility for email and maybe a good way to verify senders
without having to pay so much to Verisign for a good Gemplus RSA PKI
smartcard and the certificate server services. You can do it internally,
but it only works in a limited environment unless you have a good root CA.
I wish Verisign would offer one of those at a price under $30 per
individual. I could then keep my smartcard in the reader while I was at the
computer. Maybe a contactless type, but that would lend itself to
interception.
Just because I am paranoid, doesn’t mean the whole world is not out to get
me. I just noticed this week a major surge in spam. It had dropped for a
few weeks, but the volume has tripled this week. I switched to the news
server at OSR a while back and much prefer it to the email version. Keeps
threads together and permits reviewing, so this will not affect on most of
my desired messages. RSS is another technology that may have to be used
since email is going to the dogs. I just wish the idiots that respond to
spam would wise up or self select themselves out of the gene pool. I saw in
Consumer Reports a recent study that 2 to 3 percent of people spammed
respond either with opt-out or a purchase.
“Michal Vodicka” wrote in message
news:xxxxx@ntfsd…
Security must not depend on reverse engineering difficulty. It is security
through obscurity. Using plain sector numbers is equally secure. Well, I’m
sure you know it. Using something more random doesn’t cause any harm; it
just can’t be taken as more secure solution.
Another possibility is to use (randomised) sector number as encryption
initialization vector.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http:://www.upek.com]
> ----------
> From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on
behalf of David J. Craig[SMTP:xxxxx@yoshimuni.com]
> Reply To: Windows File Systems Devs Interest List
> Sent: Saturday, August 07, 2004 2:24 AM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Re:Bug Check when modifying IRP_MJ_QUERY_INFORMATION
for file on FAT partition
>
> This is a disk filter he said. You can use the sector address and maybe
> hash it to a more random value then use it as the salt. In some ways
doing
> an encryption file system filter is easier as you can use file offset and
> its block size modulo as the salt too. I just think a simple increasing
> value is far too easy to reverse engineer. That is why there are
companies
> that do this type of consulting. Remember that DES is now rather easy to
> break, especially when you consider that 1000 CPU systems are available.
> Even small RSA key lengths are now possible to break and even larger key
> lengths will be possible in the future. If someone finds a method to do
> large number factoring without the current brute force methods, RSA will
be
> obsolete. Who knows what the ‘no such agency’ has hidden.
>
> “Maxim S. Shatskih” wrote in message
> news:xxxxx@ntfsd…
> > > block. If you create a file of 5GB of all zeroes, does each block
> repeat
> > > the same encrypted data? If so, you need to add something to prevent
> > > compromising the key.
> >
> > XOR the data with the file block number (as salt) before encrypting.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@upek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>