您的位置 : 资讯 > 软件教程 > a16z:解决公钥密码学核心难题的三种优选方案

a16z:解决公钥密码学核心难题的三种优选方案

来源：菜鸟下载 | 更新时间：2025-04-14 区块链合集区块链文章合集

撰文：noemi glaeser，a16z crypto撰文：Chris，Techub News在公钥密码学中，一直以来都有一个难题，那就是如何将加密密钥（如公钥）正

撰文：noemi glaeser，a16z crypto

撰文：Chris，Techub News

在公钥密码学中，一直以来都有一个难题，那就是如何将加密密钥（如公钥）正确地与一个具体的身份（比如某个人或组织）关联起来。这个问题的关键在于，要有一种公开且一致的方式来显示身份和公钥之间的关系，这样大家才能放心地使用这些公钥来加密信息。

如果没有这样明确的关系，别人可能无法确定某个公钥到底属于谁，这样就有可能把加密信息发送给错误的人，导致信息泄露或其它严重的后果。在 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 数据：也就是说，假设智能合约完全依赖于链上数据，不涉及链外的数据服务或额外的数据存储。

a16z：解决公钥密码学核心难题的三种优选方案

Public Key Directory

任何人都可以通过调用智能合约，将一个没有被别人占用的 ID 也就是(id, pk)条目添加到链上目录中。

a16z：解决公钥密码学核心难题的三种优选方案

去中心化的PKI是指通过智能合约来维护一个身份（ID）和其对应公钥的目录。这个目录是公开的，并且不依赖于中心化的第三方。例如，以ENS为例，它维护了一个域名（即身份）与相关元数据的映射关系，包括该域名所解析的地址（从这些地址的交易中可以推导出公钥）。ENS是一个更复杂的系统，不仅记录公钥，还存储了其他元数据。去中心化的 PKI 的功能相对来说更简单：智能合约只需维护一个列表，记录每个身份对应的公钥即可。

当用户想要注册一个身份得时候，首先需要生成一对密钥（公钥和私钥），或者使用已经生成的密钥对，将其身份ID和公钥发送到智能合约（可能还会支付一定费用），智能合约会检查这个ID是否已经被别人注册过。如果没有被占用，智能合约就会将这个ID和公钥添加到目录中。一旦注册完成，任何人都可以通过询问智能合约来获取某个ID对应的公钥，以便加密发送消息给该用户，如果发送者之前已经加密过消息给这个用户，并且已经有了该用户的公钥，就不需要再次向智能合约请求公钥。有了公钥后，发送者可以像平常一样使用它来加密消息，然后将加密后的消息发送给接收者，接收者使用对应的私钥来解密消息，恢复原文。

我们来看看这个方法的优点和缺点：

在IBE系统中，用户并不像传统加密系统中那样自己生成一对公钥和私钥。相反，用户需要使用一个受信任的密钥生成器注册。密钥生成器拥有一对主密钥（包括主私钥 msk 和主公钥 mpk）。当用户提供自己的 ID 时，密钥生成器会使用主私钥 msk 和用户的ID来计算出一个专属于该用户的私钥。生成的私钥需要通过一个安全的渠道传递给用户，一般来说都是使用密钥交换协议来建立这个安全通道。

对于发送者来说，IBE系统简化了加密过程。发送者只需要下载一次密钥生成器的主公钥（mpk），之后就可以使用 ID 来加密消息。对于接收者来说，解密也很简单。注册用户可以使用密钥生成器发给他们的私钥来解密收到的密文。

密钥生成器的主私钥（msk）必须长期保留，因为它在系统运行期间需要不断地生成新的用户私钥。这与某些SNARK 系统中不同，后者在受信任的设置过程中生成，但可以在设置完成后销毁。而在IBE系统中，主私钥不能像SNARK中那样在初始化后删除。

即使主私钥（msk）保管得当，每个注册用户仍然需要信任密钥生成器不会读取他们的消息。这是因为密钥生成器可以随时保存一份用户私钥的副本，或者利用主私钥重新计算出用户的私钥。

密钥生成器还有可能给用户提供一个有问题或受限的私钥，这种私钥可以解密大部分消息，但无法解密某些密钥生成器设定的特定消息。这意味着密钥生成器有能力操控用户的解密能力，从而可能对用户的通信进行某种程度的控制或限制。

在RBE系统中，每个用户自己生成一对密钥（包括公钥和私钥）。用户还需要基于他们的私钥和一个公共参考字符串（CRS）来计算一些更新值（图中标记为 a）。这些更新值用于系统中的进一步操作。公共参考字符串（CRS）的存在意味着系统的设置并非完全不需要信任。然而，CRS的生成过程采用了一种称为tau 的幂的构造方法。这种构造方法可以在链上通过多个参与者协作计算完成。只要有至少一个参与者是诚实的，这个 CRS 就是安全的。

智能合约为预期数量的用户 N 进行了设置，这些用户被分组到不同的 buckets 中，当用户在系统中注册时，需要向智能合约发送自己的身份ID、公钥和更新值。智能合约会维护一组公共参数 pp，这些公共参数不同于前面提到的公共参考字符串（CRS）。可以将 pp 理解为系统中所有已注册用户公钥的简洁摘要。智能合约接收到用户的注册请求后，会对更新值进行检查，以验证它们的正确性。一旦验证通过，智能合约会将该用户的公钥乘入到 pp 中的相应 buckets 中。这一步操作相当于将新用户的公钥纳入系统的公共参数集合中，以便后续操作使用。

在基于注册的加密（RBE）系统中，用户需要在本地保存一些信息，这些信息用于帮助他们解密消息。当有新用户注册到与他们相同的组中时，这些信息需要更新。用户可以自己监控区块链来手动更新这些信息，或者智能合约可以提供最近注册的用户信息，用户可以定期获取这些更新来保持他们的解密信息是最新的。

在这个系统中，发送者只需要做两件事：

下载公共参考字符串（CRS）：这只需要下载一次，之后不需要再更新。

下载公共参数：发送者需要偶尔下载最新的公共参数。对于发送者来说，重要的是这些公共参数中包含了接收者的公钥，而不必每次都下载最新版本，只要能找到接收者的公钥就可以了。

然后，发送者使用下载的CRS、公共参数以及接收者的身份ID，就可以加密消息并发送给接收者。这意味着发送者不需要频繁更新数据，只要确保公共参数中有接收者的公钥就行。

当用户收到一条加密消息时，首先会检查自己本地存储的辅助信息，看看是否有符合某个条件的值（比如通过某个验证检查的值），如果用户在本地找不到符合条件的值，这意味着他们需要从智能合约获取最新的更新信息，一旦用户找到了合适的辅助信息值，他们就可以使用这个值和自己的私钥来解密收到的密文，从而恢复原始消息。

显然，该方案比其他两个方案更复杂。但它所需的链上存储比公钥目录要少，也避免了 IBE 的强信任假设。

简洁的参数：

在链上存储的参数大小与用户数量的关系是次线性的，这比公钥目录需要的存储量（线性增长）要小得多，但仍然不是常量，因此在这一点上不如IBE（基于身份的加密）系统。

有一定交互性的加密：

发送消息时，发送者需要一个包含目标接收者的公共参数副本。这意味着发送者需要在接收者注册后某个时间点更新这些参数，但不需要为每个接收者单独更新，因为一次更新可能包含多个接收者的密钥。总体而言，消息发送的交互性比IBE更多，但比使用公钥目录要少。

有一定交互性的解密：

和加密类似，接收者需要一份与加密时使用的公共参数版本匹配的辅助信息。当有新用户在某个分组中注册时，公共参数和辅助信息会更新，能够解密密文的值是对应于加密时使用的公共参数版本的。用户可以选择定期获取辅助信息更新，而不是每次都立即更新，除非解密失败。与公共参数更新不同的是，更频繁地获取辅助信息更新不会泄露隐私信息。

发送者匿名：

与公钥目录的情况类似，发送者可以独立加密消息（只要它有最新的参数），而不需要查询与接收者相关的特定信息。当发送者需要从链上读取信息时，这些信息与目标接收者无关（除非发送者只请求某个特定的参数得分组，但这样可能会泄露部分信息）。

透明性：

尽管系统需要通过信任设置（可能是分布式或外部管理的）来设置，并输出一个修正的CRS（公共参考字符串），但一旦设置完成，它不再依赖任何受信任的第三方或仲裁组。虽然它依赖于一个协调的第三方（智能合约），但这个系统是完全透明的，任何人都可以充当协调者或通过验证状态转换来检查其是否诚实运行（这也是为什么它可以作为智能合约实现）。此外，用户可以要求一个简洁的（非）成员资格证明，以检查他们自己或其他人是否在系统中注册。这与IBE系统不同，在IBE中，难以让受信任的第三方证明他们没有秘密地泄露解密密钥（比如保存了一个秘密副本或泄露给其他人）。相比之下，公钥目录是完全透明的。

受限的ID集合：

这里描述的是RBE构造的基本版本。为了透明地确定一个ID所属的分组，ID必须有一个公共且确定的顺序。电话号码可以简单地排序，但对任意字符串进行排序则可能非常复杂甚至不可能，因为分组的数量可能非常大或是无限的。这可以通过提供一个单独的合约来计算这种映射，或者采用后续工作中提出的 cuckoo-hashing 方法来缓解这种复杂性。

收件人匿名：