关于在minifilter中使用分组加密算法的加密写问题

相关贴：http://bbs.driverdevelop.com/htm_data/39/0704/100483.html

在prewrite写中，如果用iopb->Parameters.Write.Length作为分组加密的长度肯定不行，因为这个值始终为0x1000，即便我只写7个字节的文本文件。然而，分组加密例如AES，分组长度如果为16字节，那么注定在解密的时候失败，因为只能读7个字节的密文而正常解密需要一个分组长度16字节。

其实，这个缓冲区中前7个字节是正常的写入数据，后面的全部用'\ 0'填充，直到0x1000

"如果strlen((char*)Buffer)得到缓冲区的真实长度作为输入来进行加解密操作，那么加密是没有问题的，但读数据时解密又出现问题了，因为系统初始化时都要对每个卷中的目录进行扫描，并从中读出一些数据，这些数据是没有规则的，可能会导致strlen((char *)Buffer)等于0，不能正确的解密意味着不能初始化卷，这样就不能识别卷。"------摘录至http://bbs.driverdevelop.com/read.php?tid-100483-fpage-0-toread--page-3.html

如果从后向前搜索至不为'\0'的位置为要写入的数据长度的话，是否又可以呢？我想如过在prewrite中晓得要写入的真正长度就不会有这个问题了。

实验证明，如果用异或来加密肯定没问题，因为异或的分组长度为1，所以不会错。但如果分组长度大于1，便可能出错。请问大牛们是怎么解决这个问题的呢？还是我的分组加密思路不对？

所以说你要保证你的文件长度是分组的整数倍，不然的话解密的时候会出问题。加密的时候因为noncache都是对齐的，至少肯定也是跟你分组对齐的。

可以详细点么，如何对齐呢？我的加密并没有使用加密文件头什么来着。。。

我是有加密文件尾的，这样的话你可以自己设置文件的长度（保证对齐），然后在尾巴里记录真实长度，就行。。。

这个只是分组加密算法的最简单的要处理的问题，要对齐的地方好几个，处理起来超级麻烦的

如果用单字节的加密就不用处理对齐的问题，但是强度太弱，好像有些产品就是用的什么流加密算法

我认为用AES的CTR模式进行加解密，就不用考虑padding的问题了

        本人也思考过这个问题，但是经过试验，发现在IRP_MJ_WRITE和IRP_MJ_READ中通过iopb->Parameters.Read.Length和iopb->Parameters.Write.Length读出的写入和读取的长度分别都是32768 4096 。。。。。等等，但不管怎么变化，始终是16的整数倍，就像版主读出的那个数据0X1000转换成10进制不也是16的整数倍吗3
        我猜想Windows开发文件系统的时候似乎考虑到了文件读取和写入的数据块大小，特别是计算机识别2进制，那至少这个统计数字不会是奇数，我使用16位的AES加解密，对于Notepad结果是有效的
     但也对于Notepad有点问题，调试中读出的读出和写入数据大小始终是16的整数倍，但是解密出的文件最后几个字节老是乱码，不知道什么原因，中间没有乱码，就最后固定的几个字节
     使用这种猜想对于OFFICE文件解密也是正常的
     加密的时候出现了问题

你好，最近自己写的一个小的DEMO 想换成 AES 的加密算法，能否借鉴一下你的CTR 模式的AES 算法参考一下，谢谢了。
good_min_xu@163.com

能具体说一下你的 AES 的 CTR 模式吗？