关于文件加密标识的考虑，请版主给指导一下

我在做一个加密驱动，刚做完外围部分，现在考虑关于加密文件标识的问题。

看了一些先行者的文章，说了几个问题，我觉得很有道理：
1）加密标识应当放在文件尾部，这样比较简单。因为在打开文件后，每次读写不需要考虑实际数据的偏移（如果加密标识放在文件头，就必须每次都要重新计算）
2）在打开文件(IRP_MJ_CREATE)的时候去掉加密标识。我的理解是用SET_INFORMATION把文家长度设置为正确的长度。
3）在cleanup的时候，并且对该文件的引用等于0的时候，加上文件加密标识，仍然放在文件尾部。

我没有找到有关加密标识的内容的文章，我是这样设计的，不知道是否正确：

1.加密标识应当容易辨认，不会在加密后的文件数据中出现。

2.加密标识长度应该固定，这样可以根据文件长度减去这个标识长度迅速找到加密标识。

3.由于数据加密后可能由于采取分组加密而在实际数据后加了0后加密，使得加密后数据长度为分组长度的整数倍，所以加密标识中应该有该文件的实际数据长度。在打开文件的时候也可以根据这个长度完成去尾。

4.如果加密驱动支持多密钥的话，加密标识中应该有密钥ID，如果支持多种加密算法的话，加密标识应该包含加密算法ID。

5.我还考虑在加密标识中加上其它常量内容，比如“加密”这个字符串，或者加密标识之前全部加密后数据的散列或者CRC，减少加密标识与文件内容相同导致错误判断是否加密的概率。不过计算散列或者CRC会降低文件访问的效率。

不知道我的考虑是否正确，希望在做文件加密驱动的朋友一起讨论，也请各位大拿多多指导。

没有人在做这个吗？

那也请各位大拿指点一下啊。

版主不在家，大拿不肯泄露技术秘密，来这里没啥用啊

你的设计中1.2.3.4.5都是可行的，我就在去年实现了这样一个东西，但是和3，5梢有不同！后来我把它扔了，重新设计了加密头放在头部的，双FCB的实现...

1）加密标识应当放在文件尾部:

    Depends. I don't think one is better than the other.

2）在打开文件(IRP_MJ_CREATE)的时候去掉加密标识。
3）在cleanup的时候，并且对该文件的引用等于0的时候，加上文件加密标识，仍然放在文件尾部。

    Generally I don't like this idea. What can you do to handle power failure. I don't think a real product should use this approach.

1.加密标识应当容易辨认，不会在加密后的文件数据中出现。

    Encrypted data can be any binary data.

2.加密标识长度应该固定，这样可以根据文件长度减去这个标识长度迅速找到加密标识。

    Depends on your implementation. Fixed length may be easier to handle.

3.加密标识中应该有该文件的实际数据长度
4.如果加密驱动支持多密钥的话，加密标识中应该有密钥ID，如果支持多种加密算法的话，加密标识应该包含加密算法ID。
5.我还考虑在加密标识中加上其它常量内容，比如“加密”这个字符串，或者加密标识之前全部加密后数据的散列或者CRC，减少加密标识与文件内容相同导致错误判断是否加密的概率。不过计算散列或者CRC会降低文件访问的效率。

    All are dependent on particular implementation.

我之前在头部添加标记的处理如下，但是问题多多，
在做加密标记处理时，在IRP_MJ_CREATE 完成后在加上512个字节的头部加标记，
在IRP_MJ_READ中读到加密文件是，让位移IrpSp->Parameters.Read.ByteOffset加上512，再返回
在IRP_MJ_WRITE中写加密数据时，也让 IrpSp->Parameters.Write.ByteOffset 加上512，再返回
出现的结果是
读的时候，能正确返回从512个字节后的数据，但是后面会带有很多00
而写的时候，确依然从0处开始

引用第5楼fancylf于2009-04-14 15:32发表的  :
我之前在头部添加标记的处理如下，但是问题多多，
在做加密标记处理时，在IRP_MJ_CREATE 完成后在加上512个字节的头部加标记，
在IRP_MJ_READ中读到加密文件是，让位移IrpSp->Parameters.Read.ByteOffset加上512，再返回
在IRP_MJ_WRITE中写加密数据时，也让 IrpSp->Parameters.Write.ByteOffset 加上512，再返回
出现的结果是
.......

你的这个问题可能的原因是：如果写文件的方式是non cached，那么Offset和Length都必须跟扇区大小对齐。

牛逼啊！ 有demo 出来了吗

你头标记在IRP_MJ_CREATE 具体怎么实现的？
可能运用的函数不通也会出现这样情况

我在IRP_MJ_CREATE  里面简单地根据文件格式判断文件是否需要加密
如果需要加密，自己构建IRP发送到文件对象，在头部插入512字节的标记，其中包括移动后面的内容

引用第6楼zzbwang于2009-04-14 19:00发表的  :


你的这个问题可能的原因是：如果写文件的方式是non cached，那么Offset和Length都必须跟扇区大小对齐。

请问怎么对齐呢？谢谢！

引用
引用第6楼zzbwang于2009-04-14 19:00发表的  :


你的这个问题可能的原因是：如果写文件的方式是non cached，那么Offset和Length都必须跟扇区大小对齐。


minifilter的swapbuffer里面有这样的例子