公钥密码学难题三大解决方案：a16z解析

在公钥密码学中，如何将加密密钥与具体身份关联起来一直是个难题。这不仅是技术上的挑战，更是信任和安全性的考验。想象一下，你想给朋友发送一条加密信息，但你不确定他的公钥是否真的属于他。这就像在没有地址的情况下寄信，信息可能落入错误的人手中，导致严重的后果。在Web3世界中，这个问题依然存在，但我们有了一些新的解决方案来应对它。

目前，有三种主要方法来解决这个问题：Public Key Directory、基于身份的加密（IBE）和基于注册的加密（RBE）。每种方法都有其独特的优势和挑战。让我们深入了解一下这些方法，并看看它们在区块链上的应用情况。

三种方法的探索

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

为了解决这些问题，密码学家提出了替代方案。1984年，Adi Shamir提出了基于身份的加密（IBE），其中用户的标识（如电话号码或电子邮件）可以直接用作公钥。这消除了维护公钥目录的需要，但引入了对受信任第三方的依赖。2001年，Dan Boneh和Matthew Franklin提出了第一个实用的IBE构造，但这种技术主要在封闭的生态系统中使用，原因之一是它需要依赖一个强大的信任假设，即信任第三方生成的密钥。不过，区块链技术可以通过依赖一组参与者组成的法定人数来解决这种信任问题。

Public Key Directory

在去中心化的PKI中，智能合约维护一个身份（ID）和其对应公钥的目录。这个目录是公开的，不依赖于中心化的第三方。以ENS为例，它不仅记录公钥，还存储了其他元数据。用户可以通过智能合约注册一个身份ID和公钥，智能合约会检查这个ID是否已被占用。如果没有，ID和公钥就会被添加到目录中。任何人都可以查询某个ID对应的公钥，以便加密发送消息。这种方法的优点是非交互式解密和透明性，但缺点是不简洁和需要交互式加密。此外，发送者的身份可能无法完全保持匿名。

基于身份的加密（IBE）

在IBE系统中，用户的身份由他们的公钥表示，但需要依赖一个或多个受信任的第三方来生成并发放密钥。这些第三方还需要保管一个主密钥，用于生成用户的私钥。用户通过密钥生成器注册，提供自己的ID，密钥生成器使用主私钥和用户的ID计算出专属私钥。发送者只需下载一次密钥生成器的主公钥，就可以使用ID加密消息，接收者使用私钥解密。然而，IBE系统依赖于强信任假设，因为密钥生成器可能保存用户私钥的副本或操控用户的解密能力。

基于注册的加密（RBE）

RBE系统中，用户的身份直接充当公钥，但不再依赖受信任的第三方，而是由一个key curator取代。用户自己生成密钥，并基于私钥和公共参考字符串（CRS）计算更新值。智能合约为用户设置公共参数，用户注册时发送身份ID、公钥和更新值，智能合约验证后将公钥纳入公共参数中。发送者只需下载CRS和公共参数，就可以加密消息并发送。接收者需要本地保存辅助信息，并在有新用户注册时更新这些信息。这种方法比其他两个方案更复杂，但所需的链上存储更少，且避免了IBE的强信任假设。

总的来说，这三种方法各有优缺点。Public Key Directory提供透明性和非交互式解密，但需要交互式加密和可能无法保持发送者匿名。IBE系统提供非交互式加密和发送者匿名，但依赖于强信任假设。RBE系统则提供了一定的交互性和透明性，同时避免了强信任假设，但需要更复杂的操作和次线性的链上存储。选择哪种方法取决于具体的应用场景和需求。