@
rekulas 我又仔细读了一下算法,发现自己漏看了 keyC 是随时间变化这个关键点,所以选择明文攻击只能有限度的进行
吐槽一下那段 c 代码,看起来很头大,很多循环和变量完全都可以合并在一起,很多地方看起来很危险很容易越界的样子
下面是我看出来的一些弱点:
1. 使用了基于时间的 IV
这是最大的弱点,其使得选择明文攻击得以成为可能。仔细观察一下,你可以注意到挂出来的那个文件夹里 5+3 个文件都共享了相同的 IV ,如果计算速度足够快,就有可能整个项目共享一个 IV ,相同 IV 的文件中只要一个文件的明文已知就可以推出其他文件中至少一部分的明文内容了。原理是 ciphertext xor plaintext = key ,不详述了。
2. 加密方法暴露了密钥长度
算法没有规定最小密钥长度,这本来不算大问题,但是对 keyC 画蛇添足进行截断就会暴露原始密钥的长度。试想使用者如果设定了一个较短长度(比如 32bit )的密钥,攻击者就可以在十几分钟内通过穷举攻击破解出来。
3. 密钥空间不够大
算法一开始就把输入的 key 做了 md5 ,然后平分拆成 keyA 和 keyB , md5 输出一共才 128bit ,拆一半只有 64bit 了,由于 keyC 随密文提供,完全秘密的只有这 64bit 的 keyA ,虽然穷举 2^64 也是非常困难,但我觉得在现代密码中这也能算得上是一个设计弱点了。
4. MAC 设计有问题
我读了算法发现前面被分出来的 keyB 只在预处理明文的时候被用到过,结合上下文我大胆的猜想你是想要实现 MAC 机制。然而 MAC 机制本不需要用到密钥来实现,这里分出 keyB 既没有好处,也影响到了密钥空间的大小。
5. 过期机制的实现有问题
源码里有提到 expire 的概念,相信你是想提供过期机制吧,但这个过期只能在逻辑上做判断,并没有提供数学上的保证,如果攻击者在过期后获取到密钥,仍然可以构造出 keyA 并对文件进行解密。
综上所述,这个算法的核心就是一个内部基于 RC4 ,并且提供了初始向量支持的代码加密算法。先不说对解释执行的代码进行加密是否有意义,即使作为纯文本加密,也是有很多弱点的,而这些弱点并非理论本身的缺陷,都是在你设计加密算法时不慎引入的,我没有接受过系统的信息安全训练都能看出那么多问题,所以不建议自己设计加密算法的原因就在这里。