多次密钥
多次密钥在生活中的应用也是十分广泛的，比如文件系统中，相同的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)
- 构建方案一
值得注意的便是，iv应该是不可预测的。否则的话，攻击者可以根据IV的可预测性对它进行攻击；
- 构建方案二
这里的nonce不是随机数，而是唯一的count(比如1,2,3...)，即pair(key,n)仅仅对一个消息使用。如果接受者已经先知道nonce的话，就不需要在密文中再加入nonce了。值得注意的是，这里的 和
不应该相等。
另外，如果消息不是分组大小的整数倍，需要在最后一个分组补充字符。即便是整数倍，也需要在后面补充一个假的分组。
多次密钥 (CTR Mode)
- 构建方案一：Random CTR-Mode
与CBC不同的地方在于，这里的加密方案可以并行处理，而CBC的方案只能串行处理。
- 构建方案二：Nonce CTR-Mode
这里与方案一的区别在于nonce的构建。在这里，nonce前64bits是随机数，而后64bits是计数器（对于每个消息而言，从0开始计数）。值得注意的是，因为64位的计数器的限制，方案如果加密超过了个消息，就会出现重复使用相同nonce的问题。
CTR和CBC方案的比较
值得一次的最后一行指的是，对于一个字节的消息加密，CBC的劣势显得很明显（它需要扩展每个一子节消息到16个字节），而CTR则完全不需要。
总结我也放出来..这里就不详细描述了，看论文去了..
