多次密钥
多次密钥在生活中的应用也是十分广泛的,比如文件系统中,相同的AES Key可以用来加密多个文件;IPSec中,相同的AES Key可以加密多个包。
在这里,安全模型会与一次性密钥不同。攻击者可以执行选择明文攻击(Chosen-plaintext attack,CPA),根据攻击者的需求,他可以自由选择密文和明文组合。攻击者的目标当然都是证明这个加密方案不具备语义安全性质。
问题的关键在于,如果一个私钥被使用了很多次,那么如果加密相同的内容,其密文一定不能够一致。
Dan给出了两种解决方案:
-
第一种解决方案是使用一种随机加密的算法(Randomized Encryption),简单的将就是.这样一来,密文的长度就肯定比明文的长度要大。
Randomized Algorithm
-
第二种解决方案是基于随机数的加密方案 (Nonce-based Encryption).其中,随机数是会变化的,并且(k,r)永远不会被使用超过一次。
1.第一种方法是,把随机数看成一种定时数(Packet Counter),用来表示消息传输的一种状态数,如果通信双方拥有同步状态的话,就不需要传递nonce了。 2.第二种方法是从一个很大数据集中选择一个随机数,这样子概率会保证选出的所有的随机数没有重复的项。这种场景适合不同设备之间的加密需求(异步时钟)。
多次密钥 (CBC Mode)
- 构建方案一
Decryption circuit
值得注意的便是,iv应该是不可预测的。否则的话,攻击者可以根据IV的可预测性对它进行攻击;
- 构建方案二
这里的nonce不是随机数,而是唯一的count(比如1,2,3...),即pair(key,n)仅仅对一个消息使用。如果接受者已经先知道nonce的话,就不需要在密文中再加入nonce了。值得注意的是,这里的 和 不应该相等。
Construction2: nonce-based CBC另外,如果消息不是分组大小的整数倍,需要在最后一个分组补充字符。即便是整数倍,也需要在后面补充一个假的分组。
A CBC technicality: padding
多次密钥 (CTR Mode)
- 构建方案一:Random CTR-Mode
与CBC不同的地方在于,这里的加密方案可以并行处理,而CBC的方案只能串行处理。
Rand CTR-Mode
- 构建方案二:Nonce CTR-Mode
这里与方案一的区别在于nonce的构建。在这里,nonce前64bits是随机数,而后64bits是计数器(对于每个消息而言,从0开始计数)。值得注意的是,因为64位的计数器的限制,方案如果加密超过了个消息,就会出现重复使用相同nonce的问题。
CTR和CBC方案的比较
Comparison值得一次的最后一行指的是,对于一个字节的消息加密,CBC的劣势显得很明显(它需要扩展每个一子节消息到16个字节),而CTR则完全不需要。
总结我也放出来..这里就不详细描述了,看论文去了..
Summary
网友评论