既然是随笔，就不展开写了。直接贴一个图先。

这个项目实现的是去中心化密钥管理。Alice有私钥，公钥是，A有一段明文m，首先被Alice随机产生的对称密钥K加密后形成密文x, 放在某处（可以是不同的云服务商，也可以是IPFS等，这个不重要，只要要用的时候保证别人可以拿到就可以），然后剩下要解决的事情是如何把这个对称密钥K给到用公钥标识的接收方Bob。

上图中，代理再加密是这样运作的：

1. Alice 必须知道Bob的公钥

2. Alice产生一个可以被解密出K的capsule，当然是密文，云服务器看不到明文

3. Alice根据自己的私钥和Bob的公钥产生一个只有Bob可以用的再加密密钥，这个再加密密钥有N片, 每一片叫kFrag

4.  Alice把kFrag分散上传到不同的云服务器，一起上传的还必须有capsule

5. 云服务器可以用各自的kFrag和capsule计算产生不同的capsule fragment(cFrag)

6. Bob搜集齐备t个cFrag，加上自己的私钥，可以解密得到K

7. Bob用K解密 x 得到明文m（x本身不一定也在云上一起保存）

传统方法做可以这样：

1. Alice必须知道Bob的公钥

2. Alice用加密K，得到 K_for_B

3. Alice可以进一步用Shamir's Secret Sharing技术从 K_for_B 产生N片信息eFrag，拥有其中 t 片eFrag就可以还原 K_for_B，

4. eFrag保存在多个云上

5. Bob拿到 t 片eFrag，还原 K_ for_B

6. Bob 还原出 K

7. Bob 用K解密 x 得到明文m

比较一下：

1. 代理再加密方法下，要让Bob能够解密x，必须由Alice在一开始就为Bob度身定做N个kFrag，云服务器是无法代替Alice完成对Bob的这种授权的；传统方法也一样，Bob能解密这个事情是Alice而非云服务器去代理指定的

2. 代理再加密方法下，Alice需要在云上分散保存N个kFrag，外加N份capsule（里面包含了K的信息）；传统方法下，Alice需要上传N个eFrag分片到云；

3. 如果Carol来了，无论何种方法上述事情Alice都得再做一次

4. 无论何种方法，云服务器都看不到K的明文

5. 无论何种方法，BOB都可以从云服务器拿到t个分片后还原出K

6. 传统方法云服务器只需要保存结果，压根不需要做额外的事情就能满足要求；代理再加密方法下，云服务器如果同样不做计算而单纯保存Alice生成的cFrag，就和传统方法类似；如果产生cFrag的工作居然是云服务器去做，那只是比传统方法额外做了一个事情（传统方法Alice需要产生N个eFrag上传，但代理再加密方法下Alice也需要产生N个kFrag再上传，但后续还必须多做一步才行）

7. 传统方法算法简洁，同等安全，效率也高很多。

单独看一次共享，两相比较，看不出使用代理再加密方法解决这个密钥分发有什么必要性和优点。

代理重加密方法比传统方法有四个优点：

1.  对称加密密钥云端不出现—— 大家都是

2. 消息发送者只需要对数据/加密密钥一次加密，针对消息接受者生成对应的重加密密钥—— 没看出不指定消息接收者是如何做到的，至少PAPER里面没有提。相反的，针对不同接收者，消息发送者都一样必须事先产生不同的解密手段

3. 数据重加密在云端完成，减轻客户端压力—— 传统方法根本不需要这一步，但客户端也没有更大压力

4. 接收者获取加密数据不需要和发送者直接建立联系，发送者可以离线——传统方法也一样

所以问题的真正关键并不是这4点。经过线上探讨，所引这段文字的作者沙漏时间举出一个正确理由用来说明代理重加密方法的优势：

假设有A有F篇文档需要共享，每篇有一个对称加密密钥（彼此不同）；系统中每来一个新用户X表示对A的文档B表示潜在感兴趣的，用传统手法A需要为F篇文档替X都进行一把非对称加密，用代理重加密则需要为X产生若干个kFrag。A每增加一篇文档，传统手法下A需要为每个感兴趣者做一把非对称加密，用代理重加密则不需要新增操作。

单看一次开销，传统手法优势明显。但视文章数、关注用户数的数据量大小，两种方法各自的总体实际开销并不是永远其中一种胜过另外一种。那么是否最合理的工程实现手法是在一定范围内使用传统手法，在额外区间内切换到代理重加密手法呢？