文件头加密是否是存在着技术上无法克服的缺陷的？

不知不觉间，开发文件透明加密已经8个月了，
常用的软件在本地、网络、光盘、U盘上都不存在必出的BUG了。
现在几乎无法测试出问题了。即便是测试出，也是很偶然很偶然出一下，也无法重现的。
出现的BUG都是一些偶然出的，需要长时间测试、大数据量读写测试，才可以测试出来的。
常规的人工测试，已经无法满足我的需要。
我编写了自动化测试工具使用各种合法和不合法的参数来测试问题，
但每次长时间测出来的情况都是不一样的。
有时候是蓝屏，有时候文件读写后，内容不一致。。。
等等。
我有点怀疑是否我已经做到我的极限了，
是否采用文件头加密的方式，本身就是有技术缺陷的？
我怀疑是文件头加密的方式，破坏了文件系统本身的一些运行机制导致的。
我打算下一步重新阅读WINDOW的CACHE管理器和内存管理器的代码和文件系统的代码，如果这次阅读依然无法彻底解决所有问题。。。。。。

顺便说一下，现在的市面上做的比较好的几家公司的软件，都存在一定程度上的文件损坏和蓝屏的问题。我知道现在公司的竞争对手，好像都在为这些问题头痛，现在许多文档加密公司的人都在招人，可能也都是因为无法彻底解决这些问题。

你发现的这些问题，是很严重的问题。其实主要原因是对文件系统不了解。

文件系统除了几个api之外，还有深层次的原因，8个月的路不短，其实也不长。还需要努力。

真要把加密做好，说实话，现在国内的技术水平还真不能解决这些问题。如果要解决所有问题，基本上需要把文件系统的结构重写一遍。

文件系统加密的关键是缓存管理，但是这块，　ms没有为加密作任何准备，实际上你需要处理所有可能的缓存管理方案。最好的办法就是重写文件系统...比如一些知名的开发包(国外的)基本上就是重写了文件系统结构来实现这些功能。这样才可以实现完全的EFS支持(windows加密文件系统之上再加密),压缩磁盘支持。这些是实质上的内容

恩。非常谢谢。
现在常常想自己要写个文件系统才能真正的搞清楚这里面的所有的运行机制。
不过开发时间不容许，这些基础研究太费时间的。等哪天自己没有生存压力了，一定慢慢折腾这些东西。
微软为什么不可以提供一个简单的文件系统的例子呐？郁闷。
fat32和ntfs还是太复杂了！fat32编译后，一旦挂进去，总有进程在自动访问文件系统，打印出的调试信息量太大了,垃圾信息太多了。如果一定要调试文件系统，必须弄一个没有界面的window执行环境来，剔除所有不必要的window组件，禁止运行所有非必要的进程。

我猜测，如果一定要解决所有问题，可能必须自己接管fcb结构的管理，或者说是在文件系统上面再用过滤驱动构造一层文件系统。感觉问题出在fcb的字段上面，由于fcb可以被内存管理器和CACHE管理器以及文件系统都看到。文件头加密的情况，文件系统、内存管理、CACHE管理器看到的内容本来就是不一样的（至少文件的有效长度是不一样的）。这样一来，一些边界问题的管理机制就失效了，或者说三个模块出现了不一致的情况。新加的这一层文件系统，就是为了保持文件系统、内存管理、CACHE管理器的一致性。这个可能就是分层文件系统的一个构想吧。这个工作量太大了，不是我一个人可以搞定的东西。

不知道那个OSR的开发包到底能否解决国内的这些实际问题，看上去很美好...

所以分层的文件驱动到底能否彻底解决问题，好像也不是很明了，如果冒险去折腾，说不定又是一条不归路

任何东西，越简单越不会出问题，考虑的越复杂实现的功能越多，越容易出问题


不知道楼主那里具体是些什么问题

你写个自动化测试工具就可以测试出来的。
问题主要是两个“文件损坏”“系统蓝屏”
测试到最后，等解决了自己的代码上的所有BUG，
你会发现蓝屏之类的问题都不会出在自己的模块里。
总之一句话，编写“随机参数 长时间测试”的测试工具，这样做压力测试，做完你就可以知道我的问题了。
在开发后期，使用人工测试已经没有太大的价值了。一方面是很不容易测不出来，一方面是测试出来问题无法反复复现。必须使用自动化测试，而且就是我现在使用自动化测试，出了问题后，使用一样的操作序列，执行的结果还是有很大的随机性的。

这个是我对测试工具的功能定义，
有些已经在使用中，有些限于开发时间和技术能力没有实现，
但就实现的那部分而言，现在已经有了一些效果。

XXXX我等用磁盘加密的路过~~

xxx 陷在泥塘的爬过

这个有关测试工具的描述倒是不错,基本上能概括大部分情况

磁盘加密才是正道,FSD层的话,只有在其上面完全自己实现一掏虚拟FSD，控制所有的操作，然后通过自己的精心管理，才有可能实现，不过估计把我们这里所有的人都加起来不吃不喝的做，都搞不定。

这些加密方式各有各自的应用领域的，不存在哪种加密方式好的情况。
磁盘加密分为虚拟磁盘加密和物理磁盘加密，
虚拟磁盘加密一般是使用filedisk修改的，成熟的开源项目为pgp。
物理磁盘加密一般是使用磁盘过滤驱动修改的，成熟的开源项目为truecrypt。
这两种加密方式的代码实现都是比较简单的，核心的内核部分的代码大概有10K左右（全盘加密可能多一个BOOT模块，这个具体的工作量我不是很清楚，但可以参考TRUECRYPT），其他的所有的代码都是可以在AP上编译调试好，然后在驱动中直接使用的。就开发难度来说，都是比较简单的，开发是可以做到并行开发的，可以通过人力来堆时间的。
磁盘只适合个人用户，无法支持一台机器多用户的情况，无法支持根据不同的用户和不同的进程来判断加解密条件。而且，只要别人可以登陆机器，就可以将明文数据直接拷贝出去。这样一来，也就无法在企业级别的权限管理系统中有什么太大的用途。
磁盘加密适合商用的笔记本个人用户，适合处理“艳照门”类似的问题，但不适合处理“企业内鬼”的问题。

我的感觉就是，
个人用户用磁盘加密，（虚拟磁盘的安全性和稳定性是比全盘加密要好一些的）
小型企业用户用文件透明加密，
中大型企业使用门禁系统配合物理移动存储设备禁用、物理端口禁用和安全日志管理。

国家保密条例里明确说：所有涉密计算机不得以任何物理介质形式与ＷＥＢ相连接．不说涉密计算机里有ＩＥ　cooking,就是安装过ＱＱ等软件都要把硬盘砸了再烧！～～～～呵呵．涉密内网的房间内不得有裸漏金属构件，包括暖气．内门不得为金属，外门必须为高品质防道门，每一台机器封闭ＵＳＢ　串口　并口　．．．．．．．一堆机子用一台内网文件服务器，一台打印机．．．．．．．．使用机器落实到人，都有记录．从外面倒来的数据必须用ＵＳＢ的也只能使用红，黄，蓝三个Ｕ盘来到，还要加一台中继机器，红盘只能在涉密机器用，黄盘只能在中继和涉密的用，蓝盘只能在ＷＥＢ和中继的用．中继机器都是不能上网的，只能用于倒文件，而且还有使用特殊系统，特殊软件控制其各个接口．再利用特殊的保密管理软件对内网的每一台机器进行控制．出了就绝对是从主管校长开始一路撤职查办倒使用人．．哈哈，大家到５处喝茶．．．．．．．

呵呵。国家保密条例，太强悍了。
搜了一下
http://www.itsec.gov.cn/webportal/portal.po
安全证书太不好拿了。

现在仔细想了一下，以前的考虑考虑的多余了。
ntfs是支持压缩文件和散列文件的，现在的文件头加密也是一种类似的特殊的文件。
CACHE管理器和内存管理采用统一的接口可以支持那两类文件，不出现任何问题。
同理，文件头加密也应该是没有任何问题的。如果有问题，应该是对CACHE管理器和内存管理器理解的不够透彻。
不过如果需要支持文件头加密，必须想办法理解NTFS对压缩文件的支持方法。

透明加密，加密标识放在文件尾是比文件头更优秀的解决方案

我这才想明白，哈哈，是这样的。

说加密标识放在文件尾断电了怎么办，那就不会把它先存一下么？

而且最关键的是稳定性，对windows未来版本的兼容性，和“对系统的最小修改",从这些方面来看，文件尾是远远优秀于文件头的解决方案。

愿聆听各位大牛高见。