0%

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

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

如果没有这样明确的关系,别人可能无法确定某个公钥到底属于谁,这样就有可能把加密信息发送给错误的人,导致信息泄露或其它严重的后果。在 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集合:

日期: 2024-08-20 12:30

返回

上一页:跨越加密鸿沟:探索可持续增长的热启动问题

下一篇:一切都真的在向AppChains发展吗?