欧易OKX

欧易数字货币交易所，更快、更好、更强！

官网注册

解决公钥密码学难题的三种方案

在公钥密码学中，如何将加密密钥与具体身份关联起来一直是个难题。这不仅仅是个技术问题，更是信任和安全的问题。如果没有明确的关系，信息可能会发错人，导致泄露或其他严重后果。在Web3的世界里，这个问题依然存在。

目前有三种主要的解决方案：Public Key Directory、基于身份的加密（IBE）和基于注册的加密（RBE）。每种方法都有其独特的优缺点，比如IBE在匿名性和效率上表现不错，但需要强大的信任基础。下面我们来探讨这些方法在区块链上的应用，并比较它们的优劣。

三种方法

传统上，我们使用公钥基础设施（PKI）来将加密密钥与身份关联起来，核心是公钥目录。发送者需要通过一个受信任的第三方（比如证书颁发机构）来获取公钥。这在Web2环境中成本高且操作繁琐，而且用户面临着证书颁发机构滥用权力的风险。

为了解决这些问题，密码学家提出了替代方案。1984年，Adi Shamir提出了基于身份的加密（IBE），用户的身份（如电话号码、电子邮件或ENS域名）直接作为公钥。这样就不需要维护公钥目录了，但引入了一个新问题：需要依赖一个受信任的第三方（密钥生成器）来生成私钥。2001年，Dan Boneh和Matthew Franklin提出了第一个实用的IBE构造，但主要用于封闭的生态系统，原因之一是它依赖于强大的信任假设。

不过，这种信任问题可以通过依赖一组参与者（法定人数）来解决，而区块链技术恰好可以实现这一点。

优势和劣势

在比较这几种加密方案时，我做了两个假设：用户不会更新或撤销他们的密钥，智能合约不使用任何链下的数据可用性服务或blob数据。

Public Key Directory

任何人都可以通过智能合约将一个未被占用的ID（即(id, pk)条目）添加到链上目录中。

去中心化的PKI通过智能合约维护一个身份（ID）与其对应公钥的目录。这个目录是公开的，不依赖中心化的第三方。比如ENS，它不仅记录公钥，还存储其他元数据。去中心化的PKI功能更简单，智能合约只需维护一个列表，记录每个身份对应的公钥即可。

当用户想要注册身份时，需要生成一对密钥（公钥和私钥），将其身份ID和公钥发送到智能合约（可能还需支付费用）。智能合约检查这个ID是否已被注册，如果没有，就将ID和公钥添加到目录中。注册完成后，任何人都可以查询某个ID对应的公钥，以便加密发送消息给该用户。有了公钥后，发送者可以加密消息并发送给接收者，接收者使用私钥解密消息，恢复原文。

这种方法的优点是非交互式解密和透明性，但缺点是不简洁、需要交互式加密、发送者非匿名和任意ID的限制。

基于身份的加密 (IBE)

在IBE系统中，用户的身份由他们的公钥表示，但需要依赖一个或多个值得信赖的第三方来生成并发放密钥。这些第三方还需保管主密钥，用于解密或其他重要操作。

用户不自己生成密钥对，而是通过一个受信任的密钥生成器注册。密钥生成器使用主私钥和用户的ID计算出专属私钥，并通过安全通道传递给用户。发送者只需下载一次密钥生成器的主公钥，就可以使用ID加密消息。接收者使用私钥解密密文。

密钥生成器的主私钥必须长期保留，因为需要不断生成新用户私钥。这与某些SNARK系统不同，后者在初始化后可以销毁主私钥。用户需要信任密钥生成器不会读取他们的消息，因为密钥生成器可以保存用户私钥副本或利用主私钥重新计算用户私钥。密钥生成器还可能提供有问题的私钥，限制用户的解密能力。

IBE的优点是链上存储恒定/最小、非交互式加密、发送者匿名和任意ID，但缺点是强信任假设。

基于注册的加密 (RBE)

RBE系统中，用户的身份（如电子邮件地址或电话号码）直接充当公钥，但不依赖受信任的第三方或quorum来管理密钥，而是由一个key curator取代。我将讨论一种高效的RBE构造方式，它可以在区块链上部署，因为它是基于pairing的，而不是基于lattice的。

每个用户自己生成一对密钥，并基于私钥和公共参考字符串（CRS）计算更新值。CRS的生成采用tau的幂的构造方法，可以在链上通过多个参与者协作计算。智能合约为预期数量的用户N设置，分组到不同的buckets。用户注册时，发送身份ID、公钥和更新值，智能合约维护公共参数pp，将新用户的公钥纳入系统的公共参数集合中。

用户需要在本地保存信息用于解密，当有新用户注册到相同组时，这些信息需要更新。用户可以自己监控区块链手动更新，或通过智能合约获取更新信息。发送者只需下载CRS和公共参数，就可以加密消息并发送给接收者。接收者使用本地存储的辅助信息和私钥解密密文，恢复原始消息。

这种方案比其他两个更复杂，但链上存储比公钥目录少，避免了IBE的强信任假设。公共参数大小与用户数量的关系是次线性的，消息发送和解密有一定交互性，但发送者可以保持匿名，系统是完全透明的。ID集合有限制，但可以通过提供单独的合约或采用cuckoo-hashing方法解决。密文不会泄露收件人身份，保护了接收者的匿名性。