|
阅读：1869回复：18
各位大侠！请问在文件过滤驱动中实现动态加解密是如何实现边界对齐的啊。
请问在对文件进行动态加解密时是如何实现边界对齐的啊。
|
|
|
沙发#
发布于：2005-03-14 18:10
不需要边界对其的，我的已经完成了，不要考虑那个，读写都是以512的倍数来做的。不知道你为何要那样，说说看
|
|
驱动老牛
|
板凳#
发布于：2005-03-14 21:29
磁盘是块设备 有固定的块大小，但是不同的磁盘是不同的，比如U盘
是由硬件声明的。但是一般都是8的倍数。 |
|
|
地板#
发布于：2005-03-14 22:55
谢谢zhangshengyu
你能不能把优盘驱动给我一份阿 |
|
|
驱动老牛
|
地下室#
发布于：2005-03-15 08:40
没有驱动，是由硬件实现的 ，U盘是无驱的（用系统的）
|
|
|
5楼#
发布于：2005-03-15 11:18
不需要边界对其的，我的已经完成了，不要考虑那个，读写都是以512的倍数来做的。不知道你为何要那样，说说看 最后的尾巴怎么办？ 如果你的文件是513字节，最后那个字节怎么处理？ :) |
|
|
|
6楼#
发布于：2005-03-15 13:40
系统会自动读下个扇区的阿，不管他有多少个字节。只要你对称加密
|
|
|
7楼#
发布于：2005-03-15 21:20
先谢谢各位大哥的回复。
读写都是以512个字节的整数倍来读的（是在那一层驱动里实现这一功能的啊），这个读写好像不是通过filedisk中的ZwReadfile和ZwWriteFile来实现的吧。读和写的开始边界和长度好像都不是人工指定的，怎样保证加解密不出错呢？ 小弟对底层的东东不太了解，希望各位大哥指点一二。 |
|
|
驱动老牛
|
8楼#
发布于：2005-03-15 21:58
先谢谢各位大哥的回复。 那就看你在哪一层做的了，如果是磁盘一级，就是整块，偏移和长度都是块的整数倍，是上层磁盘驱动实现的，你不用考虑，但是只能加密整个磁盘或分区。 如果你是在文件过滤中做，嘿嘿，所有的问题都出来了。。。 |
|
|
9楼#
发布于：2005-03-15 22:18
我觉得不一定的文件过滤驱动一样可以做到的，就是加密算法铁苏
|
|
|
10楼#
发布于：2005-03-16 09:16
对于虚拟磁盘来说，filedisk不就是上层磁盘驱动吗，也就是要在它里面实现块的读写吗，是不是把读写的长度改成512字节就可以了。
但是我在论坛上看到有人说改成512字节后也不能加解密成功啊。 这个问题我一直在琢磨，百思不得其解。 谢谢大哥帮忙解答，万分感激！ |
|
|
11楼#
发布于：2005-03-16 09:45
系统会自动读下个扇区的阿，不管他有多少个字节。只要你对称加密 但是有的文件系统会将超过长度的部分清除为0； 好像ntfs就是这样的 |
|
|
|
12楼#
发布于：2005-03-16 12:05
超过长度的部分我觉得不是清除为0 ，是他本身就是0，一般格式化后，没有分配的单元都是0的，所以读写内存时，通常用memset防止碎片产生。
但是这个不影响我们加密，只要你解密也对称即可 |
|
|
13楼#
发布于：2005-03-25 09:40
超过长度的部分我觉得不是清除为0 ，是他本身就是0，一般格式化后，没有分配的单元都是0的，所以读写内存时，通常用memset防止碎片产生。 那么对于剩下的不够分组的长度怎么处理， 比如分组为8个字节，文件长度7个字节， 这7个字节如何处理？ |
|
|
|
14楼#
发布于：2005-03-25 11:29
不需要边界对其的，我的已经完成了，不要考虑那个，读写都是以512的倍数来做的。不知道你为何要那样，说说看 对磁盘驱动来说，读写是以2 ^ n对齐的，但是对于文件系统来说， 读写是random的 |
|
|
15楼#
发布于：2005-03-25 16:06
[quote]不需要边界对其的，我的已经完成了，不要考虑那个，读写都是以512的倍数来做的。不知道你为何要那样，说说看 对磁盘驱动来说，读写是以2 ^ n对齐的，但是对于文件系统来说， 读写是random的 [/quote] 是啊，如果用des加密的话，明文剩下不足8个字节的数据如何处理啊？ :) |
|
|
|
16楼#
发布于：2005-03-26 10:19
是啊，如果用des加密的话，明文剩下不足8个字节的数据如何处理啊？ 如果整个文件内容不足8字节，那只好换个加密算法或者不加密， 如果整个文件内容多于八个字节，你需要对最后几个字节做特殊处理， 比如文件内容为abcdefghijk,你先对abcdefgh加密，密文ABCDEFGH，然后你再对DEFGHijk加密，密文为XXXXXXXX。最后得到密文ABCXXXXXXXX 解密的时候先对最后八个字节解密，得到DEFGHijk，然后再解密 ABCDEFGH |
|
|
17楼#
发布于：2005-03-27 01:05
The only problem for the above solution I can see is that the last few bytes must be re-encrypted whenever there\'s change before the last few bytes.
|
|
|
18楼#
发布于：2005-03-29 09:04
[quote]是啊，如果用des加密的话，明文剩下不足8个字节的数据如何处理啊？ 如果整个文件内容不足8字节，那只好换个加密算法或者不加密， 如果整个文件内容多于八个字节，你需要对最后几个字节做特殊处理， 比如文件内容为abcdefghijk,你先对abcdefgh加密，密文ABCDEFGH，然后你再对DEFGHijk加密，密文为XXXXXXXX。最后得到密文ABCXXXXXXXX 解密的时候先对最后八个字节解密，得到DEFGHijk，然后再解密 ABCDEFGH [/quote] 如果在读写的时候做了这个处理。 那么在响应设置文件长度irp的时候还要处理吗？ :) |
|
|