在公钥密码学中，一直以来都有一个难题，那就是如何将加密密钥（如公钥）正确地与一个具体的身份（比如某个人或组织）关联起来。这个问题的关键在于，要有一种公开且一致的方式来显示身份和公钥之间的关系，这样大家才能放心地使用这些公钥来加密信息。
如果没有这样明确的关系，别人可能无法确定某个公钥到底属于谁，这样就有可能把加密信息发送给错误的人，导致信息泄露或其它严重的后果。在 Web3 中，这个问题依然存在。
对于上述的问题，目前有三种解决方案：Public Key Directory、基于身份的加密（IBE）、和基于注册的加密（RBE）。这三种方法在匿名性、交互性和效率上各有各的优点。例如，IBE 需要强大的信任基础，但在某些情况下，IBE 在匿名性和效率上表现更好。本文旨在探索这三种方法在区块链上的应用，并比较它们的优缺点。
三种方法
一般来说，将加密密钥与身份信息关联的常用方法是使用公钥基础设施（PKI），其中核心部分是一个公钥目录。在这种方法中，发送信息的人需要与一个受信任的第三方（即维护这个目录的机构，通常是证书颁发机构）进行互动，以便发送加密信息。
然而，在 Web2 的环境中，维护这个公钥目录需要较高的成本以及繁琐的操作。此外，用户还面临着证书颁发机构可能滥用权力的风险。
密码学家提出的一些替代方案，以解决公钥基础设施（PKI）存在的问题。在1984年，Adi Shamir 提出了基于身份的加密（IBE），其中一方的标识（例如电话号码、电子邮件或ENS域名）可以直接用作公钥。这种方法消除了维护公钥目录的需要，但引入了一个新的问题：必须依赖一个受信任的第三方（密钥生成器）来生成私钥。
2001年，Dan Boneh 和 Matthew Franklin 提出了第一个实用的IBE构造，但这种技术并未广泛采用，主要是在一些封闭的生态系统中使用，如企业或政府的部署环境。IBE不被广泛使用的原因之一可能是它需要依赖一个强大的信任假设，即信任第三方生成得密钥。
不过，正如本文后续将讨论的，这种信任问题可以通过依赖一个受信任的多方（即一组参与者组成的法定人数）来解决，而区块链技术可以很容易地实现这一点。
优势和劣势
比较这几种加密方案时，需要考虑许多不同的因素，我对此做出两种假设：
用户不会更新或撤销他们的密钥：这意味着在讨论中假设每个用户的密钥都是固定的，不会发生变化。
智能合约不使用任何链下的数据可用性服务（DAS）或 blob 数据：也就是说，假设智能合约完全依赖于链上数据，不涉及链外的数据服务或额外的数据存储。
Public Key Directory
任何人都可以通过调用智能合约，将一个没有被别人占用的 ID 也就是 (id, pk) 条目添加到链上目录中。
去中心化的PKI 是指通过智能合约来维护一个身份（ID）和其对应公钥的目录。这个目录是公开的，并且不依赖于中心化的第三方。例如，以 ENS 为例，它维护了一个域名（即身份）与相关元数据的映射关系，包括该域名所解析的地址（从这些地址的交易中可以推导出公钥）。ENS是一个更复杂的系统，不仅记录公钥，还存储了其他元数据。去中心化的 PKI 的功能相对来说更简单：智能合约只需维护一个列表，记录每个身份对应的公钥即可。
当用户想要注册一个身份得时候，首先需要生成一对密钥（公钥和私钥），或者使用已经生成的密钥对，将其身份ID和公钥发送到智能合约（可能还会支付一定费用），智能合约会检查这个ID是否已经被别人注册过。如果没有被占用，智能合约就会将这个ID和公钥添加到目录中。一旦注册完成，任何人都可以通过询问智能合约来获取某个ID对应的公钥，以便加密发送消息给该用户，如果发送者之前已经加密过消息给这个用户，并且已经有了该用户的公钥，就不需要再次向智能合约请求公钥。有了公钥后，发送者可以像平常一样使用它来加密消息，然后将加密后的消息发送给接收者，接收者使用对应的私钥来解密消息，恢复原文。
我们来看看这个方法的优点和缺点：
优点缺点非交互式解密 ：解密过程不需要与其他方进行互动，解密者可以独立完成解密。不简洁 (Not succinct)：系统可能在某些方面不够简洁，可能意味着复杂性较高，数据量较大，或者需要更多资源。透明性 ：系统可能在某些方面是透明的，意味着操作是公开的、可以被审查的。交互式加密 ：加密过程可能需要与其他方进行一定的互动，增加了复杂性。任意ID ：用户可以自由选择或使用任意的身份ID，而不受特定格式或规则的限制。发送者非匿名 ：发送者的身份在系统中可能无法完全保持匿名。
基于身份的加密 (IBE)
用户的身份由他们的公钥来表示，也就是说，公钥不仅用于加密，还可以作为用户的唯一标识符。但是这种方法需要依赖于一个或多个值得信赖的第三方，这些第三方负责生成并发放密钥。此外，这些第三方还需要在系统的整个生命周期内保管一个主密钥，这个主密钥在某些情况下可能用于解密或其他重要操作。
在IBE系统中，用户并不像传统加密系统中那样自己生成一对公钥和私钥。相反，用户需要使用一个受信任的密钥生成器注册。密钥生成器拥有一对主密钥（包括主私钥 msk 和主公钥 mpk）。当用户提供自己的 ID 时，密钥生成器会使用主私钥 msk 和用户的ID来计算出一个专属于该用户的私钥。生成的私钥需要通过一个安全的渠道传递给用户，一般来说都是使用密钥交换协议来建立这个安全通道。
对于发送者来说，IBE系统简化了加密过程。发送者只需要下载一次密钥生成器的主公钥（mpk），之后就可以使用 ID 来加密消息。对于接收者来说，解密也很简单。注册用户可以使用密钥生成器发给他们的私钥来解密收到的密文。
密钥生成器的主私钥（msk）必须长期保留，因为它在系统运行期间需要不断地生成新的用户私钥。这与某些 SNARK 系统中不同，后者在受信任的设置过程中生成，但可以在设置完成后销毁。而在IBE系统中，主私钥不能像SNARK中那样在初始化后删除。
即使主私钥（msk）保管得当，每个注册用户仍然需要信任密钥生成器不会读取他们的消息。这是因为密钥生成器可以随时保存一份用户私钥的副本，或者利用主私钥重新计算出用户的私钥。
密钥生成器还有可能给用户提供一个有问题或受限的私钥，这种私钥可以解密大部分消息，但无法解密某些密钥生成器设定的特定消息。这意味着密钥生成器有能力操控用户的解密能力，从而可能对用户的通信进行某种程度的控制或限制。
优点缺点链上存储恒定/最小：系统在区块链上所需的存储量很小或恒定，不会随时间增加。强信任假设：系统依赖于一个或多个受信任的第三方，这意味着需要对这些第三方有强烈的信任。如果这些第三方被破坏或不可靠，系统的安全性就会受到威胁。非交互式加密：加密过程不需要与其他方互动，发送者可以独立完成加密。发送者匿名：系统可以保持发送者的身份匿名，保护隐私。任意ID：用户可以自由选择或使用任意的身份ID，不受特定格式或规则的限制。
基于注册的加密 (RBE)
像IBE一样，在这个系统中，用户的身份（例如电子邮件地址或电话号码）直接充当他们的公钥。但与IBE不同的是，这个系统不再依赖一个受信任的第三方或一组 quorum 来管理密钥。相反，这种受信任的第三方被一个 key curator 所取代。
我将在这部分讨论一种高效的RBE构造方式，因为据我所知这与其他实用的RBE构造相比有一个显著优势，它可以在区块链上部署，因为它是 pairing-based，而不是 lattice-based 的。
在RBE系统中，每个用户自己生成一对密钥（包括公钥和私钥）。用户还需要基于他们的私钥和一个公共参考字符串（CRS）来计算一些更新值（图中标记为 a）。这些更新值用于系统中的进一步操作。公共参考字符串（CRS）的存在意味着系统的设置并非完全不需要信任。然而，CRS的生成过程采用了一种称为 tau 的幂的构造方法。这种构造方法可以在链上通过多个参与者协作计算完成。只要有至少一个参与者是诚实的，这个 CRS 就是安全的。
智能合约为预期数量的用户 N 进行了设置，这些用户被分组到不同的 buckets 中，当用户在系统中注册时，需要向智能合约发送自己的身份ID、公钥和更新值。智能合约会维护一组公共参数 pp，这些公共参数不同于前面提到的公共参考字符串（CRS）。可以将 pp 理解为系统中所有已注册用户公钥的简洁摘要。智能合约接收到用户的注册请求后，会对更新值进行检查，以验证它们的正确性。一旦验证通过，智能合约会将该用户的公钥乘入到 pp 中的相应 buckets 中。这一步操作相当于将新用户的公钥纳入系统的公共参数集合中，以便后续操作使用。
在基于注册的加密（RBE）系统中，用户需要在本地保存一些信息，这些信息用于帮助他们解密消息。当有新用户注册到与他们相同的组中时，这些信息需要更新。用户可以自己监控区块链来手动更新这些信息，或者智能合约可以提供最近注册的用户信息，用户可以定期获取这些更新来保持他们的解密信息是最新的。
在这个系统中，发送者只需要做两件事：
下载公共参考字符串（CRS）：这只需要下载一次，之后不需要再更新。
下载公共参数：发送者需要偶尔下载最新的公共参数。对于发送者来说，重要的是这些公共参数中包含了接收者的公钥，而不必每次都下载最新版本，只要能找到接收者的公钥就可以了。
然后，发送者使用下载的CRS、公共参数以及接收者的身份ID，就可以加密消息并发送给接收者。这意味着发送者不需要频繁更新数据，只要确保公共参数中有接收者的公钥就行。
当用户收到一条加密消息时，首先会检查自己本地存储的辅助信息，看看是否有符合某个条件的值（比如通过某个验证检查的值），如果用户在本地找不到符合条件的值，这意味着他们需要从智能合约获取最新的更新信息，一旦用户找到了合适的辅助信息值，他们就可以使用这个值和自己的私钥来解密收到的密文，从而恢复原始消息。
显然，该方案比其他两个方案更复杂。但它所需的链上存储比公钥目录要少，也避免了 IBE 的强信任假设。
简洁的参数：
有一定交互性的加密：
有一定交互性的解密：
发送者匿名：
透明性：
受限的ID集合：
