多次密钥

多次密钥在生活中的应用也是十分广泛的，比如文件系统中，相同的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)

• 构建方案一

Construction 1: CBC with random IV

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的问题。

nonce

CTR和CBC方案的比较

Comparison

值得一次的最后一行指的是，对于一个字节的消息加密，CBC的劣势显得很明显（它需要扩展每个一子节消息到16个字节），而CTR则完全不需要。

总结我也放出来..这里就不详细描述了，看论文去了..

Summary