区块链的密钥分配：基于注册的加密案例
本文深入分析了公钥密码学中身分与公钥关联的难题，并提出了三种解决方案：公钥目录、基于身分的加密（IBE）和基于注册的加密（RBE），详细讨论这些方案在区块链技术中的应用，包括它们如何影响匿名性、互动性和效率，同时也探讨了每种方法的优点和局限性，例如IBE 对于强信任基础的依赖和RBE 在链上储存需求上的最佳化，透过比较这些方法，读者可以更好地理解在建立安全、去中心化系统时所面临的挑战和权衡。自从引入该技术以来，将加密密钥与身份联系起来一直是一个问题。挑战在于提供并维护身份与公钥（这些身份拥有私钥）之间公开可用且一致的映射。如果没有这样的映射，原本应该保密的消息可能会出错——有时会带来灾难性的后果。同样的挑战也存在于 web3 中。
目前存在三种可能的解决方案。两种经典方法是公钥目录和基于身份的加密。第三种是基于注册的加密，直到最近它还完全是理论上的。这三种方法在匿名性、交互性和效率之间提供了不同的权衡，乍一看似乎很清楚，但区块链设置引入了新的可能性和限制。那么，这篇文章的目标是探索这个设计空间并比较这些在区块链上部署时的方法。当用户需要链上的透明度和匿名性时，实用的 RBE 方案显然是赢家——克服了基于身份的加密的强信任假设，但需要付出一定的代价。
三种方法简介
将加密密钥与身份相关联的经典方法是公钥基础设施 (PKI)，其核心是公钥目录。此方法要求潜在发送者与受信任的第三方（目录的维护者或证书颁发机构）交互以发送消息。此外，在 web2 环境中，维护此目录可能成本高昂、繁琐且容易出错，并且用户面临证书颁发机构滥用的风险。
密码学家提出了一些替代方案来规避 PKI 的问题。1984 年，Adi Shamir 提出了 基于身份的加密(IBE)，其中一方的标识符（电话号码、电子邮件、ENS 域名）用作公钥。这消除了维护公钥目录的需要，但代价是引入了受信任的第三方（密钥生成器）。Dan Boneh 和 Matthew Franklin 于 2001 年提出了第一个实用的 IBE 构造，但 IBE 并未得到广泛采用，除了在企业或政府部署等封闭生态系统中，这可能是由于强信任假设。（正如我们将在下面看到的，可以通过依赖受信任的各方法定人数来部分缓解这一假设，而区块链可以轻松实现这一点。）
第三种方案是基于注册的加密 (RBE)，于 2018 年提出。RBE 保持与 IBE 相同的通用架构，但用透明的“密钥管理员”取代了受信任的密钥生成器，该管理员仅对公共数据执行计算（具体来说，它将公钥累积成一种公开可用的“摘要”）。这个密钥管理员的透明度使区块链环境（智能合约可以充当管理员的角色）自然而然地适合 RBE。直到 2022 年，我和我的合著者介绍了第一个实用有效的 RBE 构造， RBE 才成为理论上的。
评估权衡
这个设计领域很复杂，比较这些方案需要考虑很多方面。为了简单起见，我做两个假设：
- 用户不会更新或撤销他们的密钥。
- 智能合约不使用任何链下数据可用性服务（DAS）或 blob 数据。
最后我将讨论这些额外考虑因素如何影响我们的三个潜在解决方案。
公钥目录
摘要：任何人都可以通过调用智能合约向链上表（目录）添加（id，pk）条目，前提是该 ID 尚未被认领。
去中心化 PKI 本质上是一种智能合约，它维护着身份及其对应公钥的目录。例如，以太坊名称服务 (ENS) 注册表维护着域名（“身份”）及其对应元数据的映射，包括它们解析到的地址（可以从其交易中派生出公钥）。去中心化 PKI 将提供更简单的功能：合约维护的列表将仅存储与每个 ID 对应的公钥。
要注册，用户需要生成一个密钥对（或使用之前生成的密钥对），并将其 ID 和公钥发送给合约（可能还会附带一些付款）。合约会检查该 ID 是否尚未被认领，如果没有，它会将 ID 和公钥添加到目录中。此时，任何人都可以通过向合约索要与 ID 对应的公钥来加密发送给注册用户的消息。（如果发送者之前已向该用户加密过某些内容，则无需再次询问合约。）有了公钥，发送者可以像往常一样加密其消息并将密文发送给收件人，收件人可以使用相应的密钥恢复消息。
我们来看看这个方法的属性。
负面因素：
- 不简洁。完整的密钥目录需要存储在链上，以便每个人都能随时使用（请记住，我们目前假设没有 DAS）。对于撰写本文时在 ENS 中注册的约 900K 个唯一域名，这意味着近 90MB 的持久存储空间。注册方需要支付其条目占用的存储空间，大约 65K gas（目前约为 1 美元——请参阅下面的性能评估）
- 某种程度上的交互式加密。发送者需要读取链来检索用户的公钥，但前提是这是发送者第一次加密发送给该特定用户的消息。（请记住，我们假设用户不会更新或撤销他们的密钥。）
- 发送者不是匿名的。当您检索某人的公钥时，您将自己与收件人联系起来，表明您与他们有某种关系。例如，想象一下您检索维基解密的公钥：这可能会让人怀疑您正在泄露机密文件。这个问题可以通过“掩护流量”（检索一大批密钥，其中大部分您不打算使用）或类似地通过运行完整节点或使用私人信息检索（PIR）来缓解
积极因素：
- 非交互式解密。用户使用本地存储的密钥解密消息，因此不需要交互。
- 透明。用户和密钥列表是完全公开的，因此任何人都可以检查他们是否注册正确。
- 任意ID集。 ID的域不受限制 先验 通过施工；理论上，ID 可以是 任意字符串 （取决于具体合同的实施和存储所施加的限制）。
什么时候可能想要使用公钥目录？分散式公钥目录易于设置和管理，因此是一个很好的基本选择。但是，如果担心存储成本或隐私问题，以下其他选项之一可能是更好的选择。
（阈值）基于身份的加密 (IBE)
摘要：用户的身份 是 他们的公钥。需要一个或多个受信任的第三方来颁发密钥并在系统的生命周期内保存主秘密（活板门）。
在 IBE 中，用户不会生成自己的密钥对，而是使用受信任的密钥生成器进行注册。密钥生成器有一个“主”密钥对（图中的 msk、mpk）。给定用户的 ID，密钥生成器使用主密钥 msk 和 ID 来计算用户的密钥。该密钥必须通过安全通道（可以使用 密钥交换协议）。
IBE 优化了发送者的体验：它会下载一次密钥生成器的 mpk，之后就可以使用 ID 本身将消息加密到任何 ID。解密也很简单：注册用户可以使用密钥生成器向其颁发的密钥来解密密文。
密钥生成器的主密钥比某些 SNARK 使用的受信任设置仪式产生的“有毒废物”更具持久性。密钥生成器需要它来发布任何新的密钥，因此密钥生成器无法像 SNARK 仪式的参与者那样在设置后将其删除。这也是一条危险的信息。任何拥有 msk 的人都可以解密发送给系统中任何用户的所有消息。这意味着存在持续的泄露风险，并可能带来灾难性的后果。
即使 msk 保持安全，在系统中注册的每个用户都需要信任密钥生成器不会读取其消息，因为密钥生成器可以保留用户密钥的副本或随时从 msk 重新计算它。密钥生成器甚至有可能向用户发出错误的或“受限”的密钥，该密钥解密除密钥生成器确定的一些禁止的消息之外的所有消息。
相反，这种信任可以分布在法定数量的密钥生成器中，以便用户只需要信任其中阈值数量的密钥生成器。在这种情况下，少数恶意密钥生成器无法恢复密钥或计算出错误密钥，攻击者将不得不闯入多个系统才能窃取完整的主密钥。
如果用户接受这种信任假设，（阈值）IBE 会带来很多好处（积极因素）：
- 恒定/最小链上存储。只有主公钥（单个组元素）需要存储在链上。这比链上公钥目录所需的存储要少得多。对于 BN254 曲线上的 Boneh-Franklin IBE，这意味着在设置阶段添加一次 64 字节的持久链上存储，要求服务仅花费 40K Gas。
- 非交互式加密。发送者只需要主公钥（在开始时下载一次）和接收者的 ID 来加密消息。这与公钥目录形成对比，在公钥目录中，它需要为每个想要与之通信的新用户检索密钥。
- 非交互式解密。同样，用户使用本地存储的密钥来解密消息。
- 匿名发件人。发送者不需要从链中检索任何每个接收者的信息。相比之下，在公钥注册表的情况下，发送者必须以取决于接收者的方式与合约进行交互。
- 任意ID集。与公钥注册表中一样，ID 可以是任意字符串。
但（负面因素）！
- 强信任假设。 与用户生成自己的密钥的公钥注册表不同，IBE 需要具有主密钥（陷门）的可信方或法定人数来颁发密钥。主密钥必须在系统的整个生命周期内保存，如果泄露或滥用，可能会危及所有注册用户的消息。
什么时候可能想要使用（阈值）IBE？如果有一个或多个受信任的第三方可用，并且用户愿意信任他们，那么与链上密钥注册表相比，IBE 提供了更节省空间（因此更便宜）的选项。
基于注册的加密 (RBE)
摘要：与IBE类似，用户的身份作为他们的公钥，但受信任的第三方/法定人数被替换为 透明的 累加器（称为“密钥管理器”）。
在本节中，我将讨论我论文中的高效 RBE 构造，因为与（据我所知）唯一的其他实用构造不同，它目前可在区块链上部署（基于配对而不是基于格）。每当我说“RBE”时，我都是指这种特定的构造，尽管有些说法可能适用于一般的 RBE。
在 RBE 中，用户生成自己的密钥对，并计算一些从密钥和公共参考字符串 (CRS) 派生的“更新值”（图中的a ）。尽管 CRS 的存在意味着设置并非完全不受信任，但 CRS 是一种 tau 幂构造，可以在链上协作计算，只要有一个诚实的贡献，它就是安全的。
智能合约针对预期的用户数量N进行设置，并按桶进行分组。当用户在系统中注册时，它会将其 ID、公钥和更新值发送到智能合约。智能合约维护一组公共参数 pp（不同于 CRS），可以将其视为系统中注册的所有各方公钥的简洁“摘要”。当它收到注册请求时，它会对更新值进行检查，并将公钥乘以 pp 的相应桶。
注册用户还需要在本地维护一些“辅助信息”，这些信息用于帮助解密，每当有新用户在同一个存储桶中注册时，这些信息都会被附加到本地。他们可以通过监控区块链中存储桶中的注册情况来自行更新这些信息，或者智能合约也可以通过维护从最近注册（例如，上周内）收到的更新值列表来提供帮助，用户可以定期（至少每周一次）提取这些信息。
此系统中的发送者下载一次 CRS，偶尔会下载最新版本的公共参数。对于公共参数，从发送者的角度来看，它们只关心是否包含预期接收者的公钥；它不必是最新版本。然后，发送者可以使用 CRS 和公共参数以及接收者 ID 来加密发送给接收者的消息。
收到消息后，用户检查本地存储的辅助信息中是否有通过某些检查的值。（如果没有，则意味着需要从合约中获取更新。）使用此值及其密钥，用户可以解密密文。
显然，该方案比其他两个方案更复杂。但它所需的链上存储比公钥目录要少，同时避免了 IBE 的强信任假设。
- 简洁的参数。链上存储的参数大小与用户数量呈次线性关系。这比公钥目录所需的总存储量（与用户数量呈线性关系）小得多，但仍然不是恒定的，因此与 IBE 相比更差。
- 某种程度上的交互式加密。要发送消息，发送者需要一份包含预期收件人的公共参数副本。这意味着它需要在预期收件人注册后的某个时间点更新参数，但不一定针对每个注册的预期收件人进行更新，因为一次更新可能包含多个收件人的密钥。总体而言，消息发送比 IBE 更具交互性，但比目录交互性差。
- 某种程度上的交互式解密。与加密情况类似，接收方需要一份“匹配”用于加密的公共参数版本的辅助信息副本。更具体地说，每当新用户在该存储桶中注册时，公共参数和辅助存储桶都会更新，并且能够解密密文的值是与用于加密的 pp 版本相对应的值。与公共参数更新一样，用户可以决定仅定期检索辅助更新，除非解密失败。与公共参数更新不同，更频繁地检索辅助更新不会本质上泄露信息。
- 发送者匿名。与目录情况一样，发送者可以完全自行加密消息（前提是它具有最新的参数），而无需查询收件人特定的信息。必要时，从链中读取的信息与预期收件人无关。（为了减少通信，发送者可以仅请求特定的 pp 存储桶，从而泄露部分信息。）
- 透明。尽管需要使用（可能分布式和/或外部管理的）可信设置仪式来设置系统，输出穿孔 CRS，但一旦设置完成，它就不依赖任何可信方或法定人数：尽管它依赖于协调第三方（合约），但它是完全透明的，任何人都可以成为协调者，或者通过确认其状态转换来检查他们是否诚实行事（这就是它可以作为智能合约实现的原因）。此外，用户可以要求提供简洁的（非）成员资格证明，以检查他们（或任何其他人）是否在系统中注册/未注册。这与 IBE 的情况形成对比，在 IBE 中，可信方很难证明他们没有秘密泄露解密密钥（通过制作秘密副本向自己或向他人泄露）。另一方面，公钥目录是完全透明的。
- 受限ID集。我描述了 RBE 构造的“基本”版本。为了透明地确定 ID 属于哪个存储桶，ID 必须具有公开且确定的排序。电话号码可以简单地按顺序排列，但对任意字符串进行排序非常麻烦，甚至不可能，因为存储桶的数量可能非常大或无界。可以通过提供单独的合同来计算此类映射或采用后续工作中提出的 cuckoo-hashing 方法来缓解这种情况。
带有扩展：
- 收件人匿名。该方案可以扩展，这样密文就不会泄露接收者的身份。
什么时候您可能想使用 RBE？与链上注册表相比，RBE 使用的链上存储更少，同时避免了 IBE 所需的强信任假设。与注册表相比，RBE 还为发送者提供了更强的隐私保证。但是，由于 RBE 才刚刚成为密钥管理的可行选项，我们还不确定哪些场景最能从这种属性组合中受益。如果您有任何想法，请告诉我。
性能比较
我在Colab 笔记本中估算了在链上部署这三种方法的成本（截至 2024 年 7 月 30 日） 。系统容量约为 90 万用户（撰写本文时在 ENS 中注册的唯一域名数量）的结果显示在下表中。
PKI 没有设置成本，每个用户的注册成本也很低，而 IBE 的设置成本很低，每个用户的注册几乎是免费的。RBE 的设置成本较高，而且注册成本也出乎意料的高，尽管所需的链上存储很少。
大部分注册成本（假设计算在 L2 上完成）来自于各方必须更新持久存储中的一部分公共参数，这会增加高昂的注册成本。
尽管 RBE 比其他方案更昂贵，但分析表明，它目前可以部署在以太坊主网上，而无需 PKI 或 IBE 那样存在潜在风险的信任假设。这还不包括部署多个较小（因此更便宜）的实例或使用 blob 数据等优化。鉴于 RBE 比公钥目录和 IBE 具有更强的匿名性和更少的信任假设优势，它可能对那些重视隐私和无信任设置的人具有吸引力。
作者 Noemi Glaeser 是马里兰大学和马克斯普朗克安全与隐私研究所的计算机科学博士候选人，曾于 2023 年夏天在 a16z crypto 担任研究实习生。她是美国国家科学基金会研究生奖学金获得者，之前曾在 NTT Research 担任研究实习生。
附录：其他注意事项
处理密钥更新/撤销
对于公钥目录，处理密钥更新和撤销很简单：要撤销密钥，一方要求合约将其从目录中删除。要更新密钥，将条目 (id, pk) 用新密钥 (id, pk’) 覆盖。
对于 IBE 中的撤销，Boneh 和 Franklin 建议用户定期更新密钥（例如每周），并且发送者在加密时将当前时间段包含在身份字符串中（例如“Bob <当前星期>”）。由于加密的非交互性质，发送者无法知道用户何时撤销其密钥，因此某些时间段更新是固有的。Boldyreva、Goyal 和 Kumar 提出了一种基于“模糊”IBE的更有效的撤销机制，该机制需要两个密钥来解密：“身份”密钥和额外的“时间”密钥。这样，只有时间密钥必须定期更新。用户的时间密钥累积在二叉树中，用户可以使用路径上的任何节点（在基本情况下，只有根是必要的，并且它是密钥生成器发布的唯一部分）。密钥撤销是通过不再为特定用户发布更新（从树中删除该用户路径上的节点）来实现的，在这种情况下，更新的大小会增加，但永远不会超过用户数量的对数。
我们高效的 RBE 构建没有考虑更新和撤销，后续工作提供了一个可以“升级”我们的方案以添加这些功能的编译器。
使用 DAS 将数据移至链下
使用数据可用性解决方案 (DAS) 将链上存储移至链下只会影响公钥目录和 RBE 的计算，从而将两者的链上存储量减少到相同数量。RBE 将保留对发送者更私密的优势，因为它仍然避免通过访问模式泄露收件人身份。IBE 已经拥有最少的链上存储，不会从 DAS 中受益。
声明：
本文转载自[a16zcrypto]，原文标题“Key distribution on blockchains: The case for registration-based encryption”，著作权归属原作者[诺埃米·格莱泽 ]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。
相关文章
什么是比特币?
区块链的密钥分配：基于注册的加密案例
自从引入该技术以来，将加密密钥与身份联系起来一直是一个问题。挑战在于提供并维护身份与公钥（这些身份拥有私钥）之间公开可用且一致的映射。如果没有这样的映射，原本应该保密的消息可能会出错——有时会带来灾难性的后果。同样的挑战也存在于 web3 中。
目前存在三种可能的解决方案。两种经典方法是公钥目录和基于身份的加密。第三种是基于注册的加密，直到最近它还完全是理论上的。这三种方法在匿名性、交互性和效率之间提供了不同的权衡，乍一看似乎很清楚，但区块链设置引入了新的可能性和限制。那么，这篇文章的目标是探索这个设计空间并比较这些在区块链上部署时的方法。当用户需要链上的透明度和匿名性时，实用的 RBE 方案显然是赢家——克服了基于身份的加密的强信任假设，但需要付出一定的代价。
三种方法简介
将加密密钥与身份相关联的经典方法是公钥基础设施 (PKI)，其核心是公钥目录。此方法要求潜在发送者与受信任的第三方（目录的维护者或证书颁发机构）交互以发送消息。此外，在 web2 环境中，维护此目录可能成本高昂、繁琐且容易出错，并且用户面临证书颁发机构滥用的风险。
密码学家提出了一些替代方案来规避 PKI 的问题。1984 年，Adi Shamir 提出了 基于身份的加密(IBE)，其中一方的标识符（电话号码、电子邮件、ENS 域名）用作公钥。这消除了维护公钥目录的需要，但代价是引入了受信任的第三方（密钥生成器）。Dan Boneh 和 Matthew Franklin 于 2001 年提出了第一个实用的 IBE 构造，但 IBE 并未得到广泛采用，除了在企业或政府部署等封闭生态系统中，这可能是由于强信任假设。（正如我们将在下面看到的，可以通过依赖受信任的各方法定人数来部分缓解这一假设，而区块链可以轻松实现这一点。）
第三种方案是基于注册的加密 (RBE)，于 2018 年提出。RBE 保持与 IBE 相同的通用架构，但用透明的“密钥管理员”取代了受信任的密钥生成器，该管理员仅对公共数据执行计算（具体来说，它将公钥累积成一种公开可用的“摘要”）。这个密钥管理员的透明度使区块链环境（智能合约可以充当管理员的角色）自然而然地适合 RBE。直到 2022 年，我和我的合著者介绍了第一个实用有效的 RBE 构造， RBE 才成为理论上的。
评估权衡
这个设计领域很复杂，比较这些方案需要考虑很多方面。为了简单起见，我做两个假设：
- 用户不会更新或撤销他们的密钥。
- 智能合约不使用任何链下数据可用性服务（DAS）或 blob 数据。
最后我将讨论这些额外考虑因素如何影响我们的三个潜在解决方案。
公钥目录
摘要：任何人都可以通过调用智能合约向链上表（目录）添加（id，pk）条目，前提是该 ID 尚未被认领。
去中心化 PKI 本质上是一种智能合约，它维护着身份及其对应公钥的目录。例如，以太坊名称服务 (ENS) 注册表维护着域名（“身份”）及其对应元数据的映射，包括它们解析到的地址（可以从其交易中派生出公钥）。去中心化 PKI 将提供更简单的功能：合约维护的列表将仅存储与每个 ID 对应的公钥。
要注册，用户需要生成一个密钥对（或使用之前生成的密钥对），并将其 ID 和公钥发送给合约（可能还会附带一些付款）。合约会检查该 ID 是否尚未被认领，如果没有，它会将 ID 和公钥添加到目录中。此时，任何人都可以通过向合约索要与 ID 对应的公钥来加密发送给注册用户的消息。（如果发送者之前已向该用户加密过某些内容，则无需再次询问合约。）有了公钥，发送者可以像往常一样加密其消息并将密文发送给收件人，收件人可以使用相应的密钥恢复消息。
我们来看看这个方法的属性。
负面因素：
- 不简洁。完整的密钥目录需要存储在链上，以便每个人都能随时使用（请记住，我们目前假设没有 DAS）。对于撰写本文时在 ENS 中注册的约 900K 个唯一域名，这意味着近 90MB 的持久存储空间。注册方需要支付其条目占用的存储空间，大约 65K gas（目前约为 1 美元——请参阅下面的性能评估）
- 某种程度上的交互式加密。发送者需要读取链来检索用户的公钥，但前提是这是发送者第一次加密发送给该特定用户的消息。（请记住，我们假设用户不会更新或撤销他们的密钥。）
- 发送者不是匿名的。当您检索某人的公钥时，您将自己与收件人联系起来，表明您与他们有某种关系。例如，想象一下您检索维基解密的公钥：这可能会让人怀疑您正在泄露机密文件。这个问题可以通过“掩护流量”（检索一大批密钥，其中大部分您不打算使用）或类似地通过运行完整节点或使用私人信息检索（PIR）来缓解
积极因素：
- 非交互式解密。用户使用本地存储的密钥解密消息，因此不需要交互。
- 透明。用户和密钥列表是完全公开的，因此任何人都可以检查他们是否注册正确。
- 任意ID集。 ID的域不受限制 先验 通过施工；理论上，ID 可以是 任意字符串 （取决于具体合同的实施和存储所施加的限制）。
什么时候可能想要使用公钥目录？分散式公钥目录易于设置和管理，因此是一个很好的基本选择。但是，如果担心存储成本或隐私问题，以下其他选项之一可能是更好的选择。
（阈值）基于身份的加密 (IBE)
摘要：用户的身份 是 他们的公钥。需要一个或多个受信任的第三方来颁发密钥并在系统的生命周期内保存主秘密（活板门）。
在 IBE 中，用户不会生成自己的密钥对，而是使用受信任的密钥生成器进行注册。密钥生成器有一个“主”密钥对（图中的 msk、mpk）。给定用户的 ID，密钥生成器使用主密钥 msk 和 ID 来计算用户的密钥。该密钥必须通过安全通道（可以使用 密钥交换协议）。
IBE 优化了发送者的体验：它会下载一次密钥生成器的 mpk，之后就可以使用 ID 本身将消息加密到任何 ID。解密也很简单：注册用户可以使用密钥生成器向其颁发的密钥来解密密文。
密钥生成器的主密钥比某些 SNARK 使用的受信任设置仪式产生的“有毒废物”更具持久性。密钥生成器需要它来发布任何新的密钥，因此密钥生成器无法像 SNARK 仪式的参与者那样在设置后将其删除。这也是一条危险的信息。任何拥有 msk 的人都可以解密发送给系统中任何用户的所有消息。这意味着存在持续的泄露风险，并可能带来灾难性的后果。
即使 msk 保持安全，在系统中注册的每个用户都需要信任密钥生成器不会读取其消息，因为密钥生成器可以保留用户密钥的副本或随时从 msk 重新计算它。密钥生成器甚至有可能向用户发出错误的或“受限”的密钥，该密钥解密除密钥生成器确定的一些禁止的消息之外的所有消息。
相反，这种信任可以分布在法定数量的密钥生成器中，以便用户只需要信任其中阈值数量的密钥生成器。在这种情况下，少数恶意密钥生成器无法恢复密钥或计算出错误密钥，攻击者将不得不闯入多个系统才能窃取完整的主密钥。
如果用户接受这种信任假设，（阈值）IBE 会带来很多好处（积极因素）：
- 恒定/最小链上存储。只有主公钥（单个组元素）需要存储在链上。这比链上公钥目录所需的存储要少得多。对于 BN254 曲线上的 Boneh-Franklin IBE，这意味着在设置阶段添加一次 64 字节的持久链上存储，要求服务仅花费 40K Gas。
- 非交互式加密。发送者只需要主公钥（在开始时下载一次）和接收者的 ID 来加密消息。这与公钥目录形成对比，在公钥目录中，它需要为每个想要与之通信的新用户检索密钥。
- 非交互式解密。同样，用户使用本地存储的密钥来解密消息。
- 匿名发件人。发送者不需要从链中检索任何每个接收者的信息。相比之下，在公钥注册表的情况下，发送者必须以取决于接收者的方式与合约进行交互。
- 任意ID集。与公钥注册表中一样，ID 可以是任意字符串。
但（负面因素）！
- 强信任假设。 与用户生成自己的密钥的公钥注册表不同，IBE 需要具有主密钥（陷门）的可信方或法定人数来颁发密钥。主密钥必须在系统的整个生命周期内保存，如果泄露或滥用，可能会危及所有注册用户的消息。
什么时候可能想要使用（阈值）IBE？如果有一个或多个受信任的第三方可用，并且用户愿意信任他们，那么与链上密钥注册表相比，IBE 提供了更节省空间（因此更便宜）的选项。
基于注册的加密 (RBE)
摘要：与IBE类似，用户的身份作为他们的公钥，但受信任的第三方/法定人数被替换为 透明的 累加器（称为“密钥管理器”）。
在本节中，我将讨论我论文中的高效 RBE 构造，因为与（据我所知）唯一的其他实用构造不同，它目前可在区块链上部署（基于配对而不是基于格）。每当我说“RBE”时，我都是指这种特定的构造，尽管有些说法可能适用于一般的 RBE。
在 RBE 中，用户生成自己的密钥对，并计算一些从密钥和公共参考字符串 (CRS) 派生的“更新值”（图中的a ）。尽管 CRS 的存在意味着设置并非完全不受信任，但 CRS 是一种 tau 幂构造，可以在链上协作计算，只要有一个诚实的贡献，它就是安全的。
智能合约针对预期的用户数量N进行设置，并按桶进行分组。当用户在系统中注册时，它会将其 ID、公钥和更新值发送到智能合约。智能合约维护一组公共参数 pp（不同于 CRS），可以将其视为系统中注册的所有各方公钥的简洁“摘要”。当它收到注册请求时，它会对更新值进行检查，并将公钥乘以 pp 的相应桶。
注册用户还需要在本地维护一些“辅助信息”，这些信息用于帮助解密，每当有新用户在同一个存储桶中注册时，这些信息都会被附加到本地。他们可以通过监控区块链中存储桶中的注册情况来自行更新这些信息，或者智能合约也可以通过维护从最近注册（例如，上周内）收到的更新值列表来提供帮助，用户可以定期（至少每周一次）提取这些信息。
此系统中的发送者下载一次 CRS，偶尔会下载最新版本的公共参数。对于公共参数，从发送者的角度来看，它们只关心是否包含预期接收者的公钥；它不必是最新版本。然后，发送者可以使用 CRS 和公共参数以及接收者 ID 来加密发送给接收者的消息。
收到消息后，用户检查本地存储的辅助信息中是否有通过某些检查的值。（如果没有，则意味着需要从合约中获取更新。）使用此值及其密钥，用户可以解密密文。
显然，该方案比其他两个方案更复杂。但它所需的链上存储比公钥目录要少，同时避免了 IBE 的强信任假设。
- 简洁的参数。链上存储的参数大小与用户数量呈次线性关系。这比公钥目录所需的总存储量（与用户数量呈线性关系）小得多，但仍然不是恒定的，因此与 IBE 相比更差。
- 某种程度上的交互式加密。要发送消息，发送者需要一份包含预期收件人的公共参数副本。这意味着它需要在预期收件人注册后的某个时间点更新参数，但不一定针对每个注册的预期收件人进行更新，因为一次更新可能包含多个收件人的密钥。总体而言，消息发送比 IBE 更具交互性，但比目录交互性差。
- 某种程度上的交互式解密。与加密情况类似，接收方需要一份“匹配”用于加密的公共参数版本的辅助信息副本。更具体地说，每当新用户在该存储桶中注册时，公共参数和辅助存储桶都会更新，并且能够解密密文的值是与用于加密的 pp 版本相对应的值。与公共参数更新一样，用户可以决定仅定期检索辅助更新，除非解密失败。与公共参数更新不同，更频繁地检索辅助更新不会本质上泄露信息。
- 发送者匿名。与目录情况一样，发送者可以完全自行加密消息（前提是它具有最新的参数），而无需查询收件人特定的信息。必要时，从链中读取的信息与预期收件人无关。（为了减少通信，发送者可以仅请求特定的 pp 存储桶，从而泄露部分信息。）
- 透明。尽管需要使用（可能分布式和/或外部管理的）可信设置仪式来设置系统，输出穿孔 CRS，但一旦设置完成，它就不依赖任何可信方或法定人数：尽管它依赖于协调第三方（合约），但它是完全透明的，任何人都可以成为协调者，或者通过确认其状态转换来检查他们是否诚实行事（这就是它可以作为智能合约实现的原因）。此外，用户可以要求提供简洁的（非）成员资格证明，以检查他们（或任何其他人）是否在系统中注册/未注册。这与 IBE 的情况形成对比，在 IBE 中，可信方很难证明他们没有秘密泄露解密密钥（通过制作秘密副本向自己或向他人泄露）。另一方面，公钥目录是完全透明的。
- 受限ID集。我描述了 RBE 构造的“基本”版本。为了透明地确定 ID 属于哪个存储桶，ID 必须具有公开且确定的排序。电话号码可以简单地按顺序排列，但对任意字符串进行排序非常麻烦，甚至不可能，因为存储桶的数量可能非常大或无界。可以通过提供单独的合同来计算此类映射或采用后续工作中提出的 cuckoo-hashing 方法来缓解这种情况。
带有扩展：
- 收件人匿名。该方案可以扩展，这样密文就不会泄露接收者的身份。
什么时候您可能想使用 RBE？与链上注册表相比，RBE 使用的链上存储更少，同时避免了 IBE 所需的强信任假设。与注册表相比，RBE 还为发送者提供了更强的隐私保证。但是，由于 RBE 才刚刚成为密钥管理的可行选项，我们还不确定哪些场景最能从这种属性组合中受益。如果您有任何想法，请告诉我。
性能比较
我在Colab 笔记本中估算了在链上部署这三种方法的成本（截至 2024 年 7 月 30 日） 。系统容量约为 90 万用户（撰写本文时在 ENS 中注册的唯一域名数量）的结果显示在下表中。
PKI 没有设置成本，每个用户的注册成本也很低，而 IBE 的设置成本很低，每个用户的注册几乎是免费的。RBE 的设置成本较高，而且注册成本也出乎意料的高，尽管所需的链上存储很少。
大部分注册成本（假设计算在 L2 上完成）来自于各方必须更新持久存储中的一部分公共参数，这会增加高昂的注册成本。
尽管 RBE 比其他方案更昂贵，但分析表明，它目前可以部署在以太坊主网上，而无需 PKI 或 IBE 那样存在潜在风险的信任假设。这还不包括部署多个较小（因此更便宜）的实例或使用 blob 数据等优化。鉴于 RBE 比公钥目录和 IBE 具有更强的匿名性和更少的信任假设优势，它可能对那些重视隐私和无信任设置的人具有吸引力。
作者 Noemi Glaeser 是马里兰大学和马克斯普朗克安全与隐私研究所的计算机科学博士候选人，曾于 2023 年夏天在 a16z crypto 担任研究实习生。她是美国国家科学基金会研究生奖学金获得者，之前曾在 NTT Research 担任研究实习生。
附录：其他注意事项
处理密钥更新/撤销
对于公钥目录，处理密钥更新和撤销很简单：要撤销密钥，一方要求合约将其从目录中删除。要更新密钥，将条目 (id, pk) 用新密钥 (id, pk’) 覆盖。
对于 IBE 中的撤销，Boneh 和 Franklin 建议用户定期更新密钥（例如每周），并且发送者在加密时将当前时间段包含在身份字符串中（例如“Bob <当前星期>”）。由于加密的非交互性质，发送者无法知道用户何时撤销其密钥，因此某些时间段更新是固有的。Boldyreva、Goyal 和 Kumar 提出了一种基于“模糊”IBE的更有效的撤销机制，该机制需要两个密钥来解密：“身份”密钥和额外的“时间”密钥。这样，只有时间密钥必须定期更新。用户的时间密钥累积在二叉树中，用户可以使用路径上的任何节点（在基本情况下，只有根是必要的，并且它是密钥生成器发布的唯一部分）。密钥撤销是通过不再为特定用户发布更新（从树中删除该用户路径上的节点）来实现的，在这种情况下，更新的大小会增加，但永远不会超过用户数量的对数。
我们高效的 RBE 构建没有考虑更新和撤销，后续工作提供了一个可以“升级”我们的方案以添加这些功能的编译器。
使用 DAS 将数据移至链下
使用数据可用性解决方案 (DAS) 将链上存储移至链下只会影响公钥目录和 RBE 的计算，从而将两者的链上存储量减少到相同数量。RBE 将保留对发送者更私密的优势，因为它仍然避免通过访问模式泄露收件人身份。IBE 已经拥有最少的链上存储，不会从 DAS 中受益。
声明：
本文转载自[a16zcrypto]，原文标题“Key distribution on blockchains: The case for registration-based encryption”，著作权归属原作者[诺埃米·格莱泽 ]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。
相关文章