Is it possible that NOT change file's size with AES128 in encrypt/decrypt?

NTFSD
1

Hi,

I am working on a encrypt/decrypt FS minifilter with AES128(16 bytes) algorithm on-fly.

Now I do NOT want to change file’s size when encrypt/decrypt, if file’s size is divisible by
16bytes, I can easilly do it; but if file’s size is NOT divisible by 16bytes, I must pad it until it is divisible by 16bytes, then I encrypt the file, so the size of file written to Hard disk has changed. If before sending to FSD, I cut the padded data, then file’s size do NOT change, but when decrypt, I am afraid I CAN NOT decrypt the data. How Can I solve the question? 3ks.

2

You need to keep the padding on the last block of the
cyphertext in order to decrypt correctly.
Cheers
Dave

— xxxxx@yahoo.com.cn wrote:

Hi,

I am working on a encrypt/decrypt FS minifilter
with AES128(16 bytes) algorithm on-fly.

Now I do NOT want to change file’s size when
encrypt/decrypt, if file’s size is divisible by
16bytes, I can easilly do it; but if file’s size is
NOT divisible by 16bytes, I must pad it until it is
divisible by 16bytes, then I encrypt the file, so
the size of file written to Hard disk has changed.
If before sending to FSD, I cut the padded data,
then file’s size do NOT change, but when decrypt, I
am afraid I CAN NOT decrypt the data. How Can I
solve the question? 3ks.

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

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

Get news delivered with the All new Yahoo! Mail. Enjoy RSS feeds right on your Mail page. Start today at http://mrd.mail.yahoo.com/try_beta?.intl=ca

3

Oh boy… you’re a long way from a home run.
If you require block aligned file size you either:

  • Use ECB mode, hence your security is broken from the start
  • Use other non-CTR mode (non stream), in which case your approach would lead to a requirement of reading the entire file just to en/decrypt a single chunk and would be too slow for any use.
    So change your algorithm to use CTR (counter, not always referred to as CTR for some reason) instead.

xxxxx@yahoo.com.cn wrote:

Hi,

I am working on a encrypt/decrypt FS minifilter with AES128(16 bytes) algorithm on-fly.

Now I do NOT want to change file’s size when encrypt/decrypt, if file’s size is divisible by
16bytes, I can easilly do it; but if file’s size is NOT divisible by 16bytes, I must pad it until it is divisible by 16bytes, then I encrypt the file, so the size of file written to Hard disk has changed. If before sending to FSD, I cut the padded data, then file’s size do NOT change, but when decrypt, I am afraid I CAN NOT decrypt the data. How Can I solve the question? 3ks.

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

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

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

4

Hi,

Thank U, but if file size<16 bytes, I can NOT keep the padding on the last block of the
cyphertext.

5

Which part of Counter Mode require padding?

xxxxx@yahoo.com.cn wrote:

Hi,

Thank U, but if file size<16 bytes, I can NOT keep the padding on the last block of the
cyphertext.

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

6

Hi,

Is CBC the most secure in CTR, OFB, CFB, CBC and CTR fastest?

And only CBC need padding? 3ks

7

CTS is most secure (similar to CBC, but requires >16bytes of file size), IIRC.
But these are not feasible for a file system filter, for your will have big
performance penalty. CBC requires block-aligned buffers, CTS required at least
block_size + 1 bytes.

xxxxx@yahoo.com.cn wrote:

Hi,

Is CBC the most secure in CTR, OFB, CFB, CBC and CTR fastest?

And only CBC need padding? 3ks

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