上一期我们说到 Alice 利用 Filecoin 网络分享调研报告给 Bob，为了在将调研报告传给 Bob 的过程中数据不被泄露，她采用 Bob 的公钥对调研报告再次进行加密，并将得到的密文传给了 Bob。
图片来源于网络
然而，当多个朋友想让 Alice 共享其文档时，她又陷入了烦恼，如何更便捷地将密文数据分享给其他人？
我们在后台收到了一些答复，大家提供了各式各样的解决方法。其中热心粉丝@赵敬 提到的“代理重加密”可以有效解决这一问题。
这一期我们将详细揭晓。
我们看到，在诸如此类的很多应用场合下，实际上一个本质的需求都是把原先由公钥 pk1对消息 m 加密所得的密文 c1转换为由公钥 pk2对同一个消息 m 加密所得的密文 c2。细细观察，在这样一个“加密-上传-下载-解密-再加密-上传-下载-再解密”过程中，如果能将中间“解密-再加密”这样两步由一个第三方或者说是代理者完成，即代理者能帮助完成从密文 c1到密文 c2的转换，Alice 不仅可以减少大量的计算开销，也可以省却一些下载上传的通信开销。
图片来源于网络
代理重加密（Proxy Re-Encryption, PRE）系统，是一个可以较好地解决此类问题的方案。在 1998 年的欧洲密码学年会上，密码学者 Blaze、Bleumer 和 Strauss 提出了代理重加密的概念。从此，代理重加密作为一个重要的密码学原语得到了深刻的研究和快速的发展。在代理重加密中，一个代理者（Proxy） 获得由授权人（Delegator）产生的、针对特定被授权人（Delegatee）的重加密密钥（Re-Encryption Key）后，能够利用该重加密密钥将原本采用授权人公钥加密的密文转换成利用该被授权人公钥加密的密文。在上面的例子中，Alice 是授权人，Bob 是被授权人。
在代理重加密中，一般认为代理者（转换服务提供者）是半可信的，即它虽然对密文所对应的明文好奇，但它仍然能忠实地执行它所需要完成的操作。在这个过程中，重加密密钥，或者称为转换密钥，就是用来让代理者完成“解密-再加密”这样一个过程所需的信息。虽然代理者拥有重加密密钥，他依然无法获取关于密文中对应明文的任何信息，也无法获得授权人的私钥。
根据重加密密钥所具备的能力和性质，代理重加密分为单向（unidirectional）代理重加密和双向 （bidirectional）代理重加密两种。
- 在单向代理重加密中，代理者利用重加密密钥能将 Alice 的密文转换成 Bob 的密文，而无法将 Bob 的密文转换成 Alice 的密文。
- 在双向代理重加密中，代理者能进行双向转换，即可利用重加密密钥将 Alice 的密文转换成 Bob 的密文，又可利用重加密密钥将 Bob 的密文转换成 Alice 的密文。
根据密文能否被多次转换这一性质，代理重加密又可分为单跳 （single-hop）代理重加密和多跳 （multi-hop）代理重加密。在单跳代理重加密中，Alice 的密文转换为 Bob 的密文后，不能再在针对 Bob 的密文基础上，将其转换成针对 Carl 的密文。而在多跳代理重加密中，针对 Bob 的密文可以再次被转换成针对 Carl 的密文，并可被依次转换给其他人。
图片来源于网络
我们上面谈到的代理重加密都没有限制代理者的转换能力，即只要代理者拥有 Alice 生成的重加密密钥，它可以将所有 Alice 的密文都转换成 Bob 的密文。在实际应用中，这可能有些不恰当。Alice 会有一些经由同一个密钥加密的信息不想被 Bob 知道。因此，这催生了条件代理重加密的概念。在条件代理重加密中，授权人可以根据自己想要设定的条件来生成（带条件的）重加密密钥，拥有该重加密密钥的代理者只能转换满足预设条件的密文。这种方法可以较好地控制代理者的权限。
图片来源于网络
代理重加密在实际生活中拥有较强的应用需求。现代商业中电子邮件扮演了重要的通信角色，在涉及到商业机密时，更会采用加密电子邮件系统。采用代理重加密系统，公司 CEO 在不便处理加密邮件时，比如在飞机上等，可由邮件服务器将加密邮件转换发给其助手处理。在数据作为生产要素的今天，将有更多的场景将代理重加密技术和区块链等分布式技术等结合起来，为实际应用创造更大的价值。在以后的技术视点中，我们将深入一些代理重加密的方案中，剖析如何实现这样一种系统。
有奖征稿，可通过：research@ont.io 与我们联络。
▿点击阅读原文了解更多
